아마도, MoniWiki나 MediaWiki 같은 경우 XE와 연동하려??? 상당히 수정해야 할 것으로 보입니다. 더해서 MoniWiki나 MediaWiki에 CUBRID 지원까지 넣어야 할 것 같네요. 오히려 WikiXE를 수정하는 것이 빠르지 않을까... 싶습니???. 저도 MoniWiki가 더 익숙합니다만(MediaWiki는 써 본 적이 없구요) 일단은 어쩔 수 없을 거 같네요.

저도 WikiXE에서 기존 MoniWiki에서 쓰던 문법들이 지원되면 ???겠습니다. 더해서 지금 WikiXE에 일부 자료 링크 등에 대한 버그가 있는 것 같네요. 그건 현재 WikiXE 프로젝트에서 SVN으로 현재까지 수정된 버전을 export 받아서 사용하면 문제가 없겠지만, 문법 지원 기능이나 formatter 쪽 지원 같은게 상당히 마음에 걸리네요.

결???: 일단 저도 그렇게 하고 싶지만 그렇게 하는 거 보???는 차라리 WikiXE를 수정하는 것이 나아 보이고 시간??? 덜 들 것 같구요. 무엇보다 회원 정보 관련 연동이 ???우 어렵습니다.

흠.. DB를 사용하지 않는 wiki를 사용한다면 부담은 ??? 적어질듯합니다만...

적어도 moniwiki는 mysql을 ???용하지 않는것으로 알고있는데요....

그렇게되??? login check부분만 수정하면 되지 않을려나요?

뭐 wikiXE가 다른 wiki처럼 수정되는것도 상관은 없겠지만 아무래도 엔진의 문제라....
그쪽이 시???이 더 걸리지 않을까..해서 드려본 얘기였습니다 ㅎ???ㅎ

아. 그러고 보니 MoniWiki는 DB를 쓰지 않았군요. 인증도 쿠키로 했던 거 같고. 저도 모니위키 예전 버전으??? 돌리는 위키가 하나 잇으면서 생각을 못했습니다.

제가 겁나는건 보안이나 그런 쪽이네요. 웹 프로그래머라고 하기엔 제 능력이 너무 딸리고 더부러 웹쪽 보안에 대해선 막연한 개념만 있는 상태라 잘못 ???드려서 망가트리지나 않을까 하는 생각이 드네요. ???히려 사이트를 nForge 같은 걸로 하면 어땠을까 생각??? 해 보지만, 그랬다면 또 기존 자료를 옮기지 못했을 거라는 생각도 들고 역시 솔루션 고민하는건 여러 ???지 측면에서 머리가 아프네요. ㅎㅎ.

웹 프로그??? 쪽으로는 자원이 되시는 분들이 계신다면 함께 해 보면 좋겠습니다. 제가 하긴 조금 버겁거든요. 전 HTML/CSS, PHP 좀 쓸 줄 아는 정도라서요 ㅎㅎ.

아, 그리고 WikiXE의 수정이라면.. 시간은 걸리겠지??? 인증이나 그런 부분을 건드리지 않고 formatting 부분??? 건드리는 거면... 제가 한 번 해 볼만도 할 것 같습???다. = =, == ==, === === 요거 구현하는 거 정도 까진 어???게 될 거 같습니다. table이나 기타 목록 등을 구현하???니 조금 복잡해 지긴 하지만, 자체적으로 해결을 못한다면 다른 코드를 좀 채용하는 방법도 있겠조.

사실 제 입장에선 MoniWiki를 수정하는 것이 WikiXE를 수정하는 것 보다 겁나는 일이기 때문에 이런 소리를 ???거리고 있습니다 아하하... 하지만 두 가지 방법 다 ???도해 볼 필요는 있는 것 같네요.