MoniWiki 차차기 버전은 개인위키 이상이 될 수도 있다. CVS혹은 arch, subversion을 백앤드로 쓰고, SQL은 Cache로만 쓴다.

버전 컨트롤을 SQL로 하지 않으려는 이유는, DB설계하기가 너무 복잡해지기 때문이다.

예를 들자면, tavi는 DB가 MySQL›1을 쓰는 경우인데, 소스를 보면 diff조작을 하기 위해서 DB에서 예전 버전과 최신 버전을 읽어서 임시 파일로 저장하고, 그 임시 파일을 diff하는 식이다. (물론, PhpWiki›2의 difflib.php를 이용하면 이 방법이 필요 없이, 각 파일을 fetch해서 $diff_out= new diff($ord,$new); 하면 된다.)

DB는 설계가 복잡하지 않아야 한다고 생각한다. 필드를 덕지덕지 늘리고 어려워 보이는 것을 기교로 알겠지만, 쉬워야 유지보수가 쉽다. 빠른 서치를 위해서라면 DB캐쉬를 따로 설계하고 원래 데이터는 자주 갱신시키거나 하지 않아야 하고, 이런 식으로 DB설계가 간단할 수록 다른 시스템으로 이식하기 쉬워지기 때문이고, 백앤드도 그만큼 단순해 질 것이다.

subversion을 언젠가 훝어봤는데, 여기 저기 디펜던시가 많았다. CVS는 단순한 편이지만 arch나 subversion에 비해 미흡한 기능.

SQL을 이용하는 버전을 만드실 계획은 없나요? 웹호스팅에서 대부분 MySQL›1을 지원하고 많은 개인위키들이 웹호스팅을 이용하니까 개인위키를 지향하는 모니위키도 DB를 지원했으면 좋겠습니다. --pok

애초에 개인위키를 목표로 했기 때문에 MySQL›1은 고려를 안했었지만, 제가 시간이 남아 돌면 MoniWikiFuture에서 쓴 것처럼, cvs arch subversion과 SQL을 지원하게 고칠 것입니다. SQL은 단지 캐쉬로 쓸 예정이고, 고치는 부분은 현재 RCS를 쓰고 있는 WikiDB를 cvs, arch, subversion에서도 가능하게 하는 것이죠. 첫째 타겟은 CVS가 될 것으로 생각합니다. --WkPark

advanced님이 SQL캐쉬 기능을 넣으셨습니다. @.@ 현재 기존의 코드와 좀 더 효율적으로 연동하기 위해 소스를 고치는 중이며, MySQL›1캐쉬 기능이 들어가게 되면 서치가 빨라지고, 페이지 개수에 거의 상관 없는 퍼포먼스를 가지게 될 것이라 생각됩니다.

이와 더불어 CVS백엔드를 붙였습니다. CVS와 RCS는 크게 다르지 않고, 위키의 히스토리기능은 CVS,RCS의 가장 기본적인 기능만 사용하게 되므로 어렵지 않게 붙일 수 있었습니다. Subversion도 고려해 보아야겠군요 @.@ --WkPark

See TwinPages:MoniWikiFuture