[ ] 로 묶은 글은 그 안의 내용으로 제목 검색을 하게 하는 하이퍼링크 적용. 클릭하면 해당 제목의 포스트로 바로 이동. 해당 제목의 포스트가 없을 때는 어드민일 때 '이 제목으로 포스트 생성, 비슷한 제목의 포스트들...' 등등 출력. 그런데 이렇게 하면 부하가 줄더라도 아직 포스트가 없는 제목을 구별해서 표시할 수 없으니까 문제가 되는군요. -_-
제목 충돌이 있을 경우에는 최선의(제 생각에는 최초의) 포스트로 이동하게 하고 제목 하단에 여타 포스트들 링크를 표시(위키피디아처럼).
제목 충돌이 있을 때 포스트를 특정할 수 있도록 [] 안에서 구별 접미사같은 것도 가능하겠지만.. 문법이 복잡해지는 것도 그렇고, 가능한 제목 충돌을 피하게끔 유도하도록 일부러 제공하지 않는 편이 좋다고 생각합니다.
역링크는 포스트 제목 옆에 출력시키도록 해야겠고요.
버전관리와 RecentChanges는 있으면 좋을텐데 개인적으로는 변경점을 개별 포스트에 물려서 저장해서 하는 것보다, 포스트번호와 diff를 한 데 저장해서 처리하는 게 낫지 않나 싶어요. RecentChanges가 적당히 길다면, 그보다 이전에 있었던 변경사항은 사실 잘 들여다보지 않으니까요.

[] 로 묶인 글들의 경우...
다음과 같이 처리하면, 해당문서의 존재여부 검색 (문서 생성시에 생기는) 의 문제가 해결되지 않을까요?
제가 html, link 등의 태그(??)에 익숙치 않아서 걍 이렇게 적습니다.

예를들어, [wiki:my_carrier] 라는 태그의 경우, html 코드를 만들때
(걍 wiki는 위키문서라는 키워드, ":" 뒤가 이름이라고 가정하겠습니다. 즉 이경우는 위키문서 혹은 제목이 my_carrier 라는 ..)
<a href="http://.../tt/wiki?my_carrier">my_carrier</a>
라는 식으로 만들게 되면, 클릭시 wiki 쿼리를 통해서,
1) 해당 문서가 존재하는지 확인하고, 그 문서가 존재하면, 그 문서로 포워딩을,
2) 존재하지 않을경우, 어드민의 경우 문서 생성질의 페이지로, 게스트일 경우 문서가 존재하지 않는다는 메세지 페이지로 포워딩을
하면 자연스럽게 처리되지 않을까 합니다.
아니면,
1) 어드민일 경우, 해당 문서가 존재하면 그 문서를 오픈, 문서가 존재하지 않으면 문서 생성 페이지로,
2) 게스트일 경우
   a) 해당 문서가 존재하고 읽기 권한이 있으면, 그 문서를 오픈,
   b) 해당 문서가 존재하지 않거나, 읽기 권한이 없으면, 그냥 텍스트 표시
등으로 처리하면, tattertools 관리 php의 부하를 좀 더 덜 수 있을 듯 보입니다.

diff 저장에 대해서는,
DB에 해당 페이지를 적을때,
wiki_document_1
이라는 문서에
version 1 으로 "this document is version 1"
의 글이 있었고,
version 2 로 "this documente is updated as version 2"
로 업뎃을 할 경우
실제로 데이터가 저장될때

와 같이 저장을 할 경우,
(@는 버전구분을 위한 미리 예약된 구분자라고 가정하겠습니다.)
1) 페이지를 보여줄 때, 단순히 최상의 버전의 텍스트를 보여구조,
2) diff를 볼 때는, 이미 버전간의 차이에 해당하는 데이터가 있으므로, 그 diff를 보여주면
되지 않을까 합니다.
이렇게 하면,
해당 페이지를 단순이 보기 할 때에, 서버가 코드 생성시 부담해야 하는 부하가 거의 없구요,
해당 페이지의 diff를 볼 때에만, diff계산을 위한 처리가 있으면 되기 때문에,
서버의 부담을 많이 줄일 수 있지 않을까 합니다.

위키의 특정 키워드 등을 활설화 해 주는것도 위키문서 작성 뿐만 아니라, 블로그 작성시에 매우 도움이 되지 않을까..
블로그 작성시에 테이블이나, 링크등의 html tag를 매우 정확하게 맞춰 쓰는경우가 많지는 않을것으로 봅니다.
그래서.. ^^;;; (희망사항이 점점 더 늘어나는 듯.. ^^)
위키의
- "*" (줄 맨 앞에 사용되면 자동 <li>기능)
- "#" (줄 맨 앞에 사용되면 자동으로 번호가 붙는 기능)
- "|" (줄 맨 앞에 사용시, 테이블 생성기능 (이는 좀 parsing 및 table 작성에 어려움이 있으려나...) )
- " " (줄 맨 앞에 공백 사용시, 자동으로 블록으로 보이게 해 주는 기능)
등과 같은 몇가지 간단한 기능을 활성화 해 주면 매우 유용할 듯 보이네요..

이런 기능은 굳이 위키뿐만이 아니라, 테더블로그 작성시에도 매우 유용하게 사용되지 않을 까 하는 생각이 드네요...

htna (2006-08-04 23:29:30)에 의해 마지막으로 수정

제가 처음에 적은 게 그런 내용입니다. 하이퍼링크에 키워드만 기재하고 실제 검색은 링크가 호출되었을 때 이뤄지는 그런. 그런데 페이지가 존재하는지 안 하는지를 클릭하기 전에는 전혀 예상할 수 없다는 문제가 생깁니다. "아직 공사중입니다." 수준으로 사용성이 나쁘고, 위키의 '없는 페이지를 채워넣으려는 동기유발'도 안 됩니다. 그런 문제가 있으니까 어쨌든 페이지를 출력할 때 제목을 검색할 수밖에 없지 않을까 싶습니다.

그리고 기존 위키(특히 노스모크모인모인, 모니위키 계열의)에 익숙한 사람이라면 [wiki:PageName]의 형식은 인터위키로, 내부 페이지는 [PageName]과 PageName의 형식으로 쓰는 것을 이왕이면 선호할 겁니다.

위키에서 텍스트는 저장할 때마다 불어나지만 (전통적인 방식에서는 맞춤법 수정으로 저장을 9번 하면 용량이 10배로 불어버립니다, 그래서 rcs를 쓰거나 합니다) 정작 diff를 들여다볼 일은 사실 최근에 수정된 것 밖에 없거든요. diff 호출은 RecentChanges 범위에 완전히 집중되어 있습니다. (만일 diff가 유용할 일이 있다면 그건 diff로 남겨놓을 게 아니라 본문에 반영해놓아야 하는 것이죠.) 나머지는 순전히 낭비입니다. 그 오래된 구버전들을 정리할 때 언급하신 방식으로는 매번 본문 테이블 전체를 긁어야 합니다. 그리고 diff 작업이 빈도가 높은 게 아닌데 본문에다 모두 모아놓는 건 다른 작업에서 손해겠죠. (특히 본문검색은)

모인모인 문법(특히 테이블 만들기)이면 릴리즈해주세요~

모두 적지는 않았습니다만,
페이지를 저장할 때, 새로운 버전으로 저장할 지를 선택하도록 하는것이 유용하다고 봅니다.
예를들어,
이미 "version 3, version 2, version 1" 이 같이 기록되어 있는 상황에서,
(저장 순서는 최근버전을 먼저 저장한다고 가정하겠습니다.)
새로 저장할 때에, "save as new version" 등 과 같은 키워드를 선택하지 않고 저장한다면.
  "updated version 3, version 2, version 1" 로 저장하고,
"save as new version" 등 과 같은 키워드를 선택하였다면,
  "version 4, version 3, version 2, version 1" 로 저장한다고 생각했습니다.

기존의 버전을 하나의 화일에 넣는것에 대해서 생각한 이유는,

diff로 데이터를 저장하게 되면,
매번 그 페이지로 html 페이지를 만들때마다,
(1) diff로 구성되어 있는 화일로부터, 온전한 화일을 만들고,
(2) 온전하게 만들어진 화일로 html 페이지를 구성
해야하는 2단계 작업으로 됩니다. 그렇기에, 해당 서버의 리소스를 많이 잡아먹겠죠..
더구나,
- 소스페이지에 문제가 있거나(디버깅을 해야 하거나),
- 유저가 직접 페이지 정보를 참조해야 하는 경우(새로운 버전이나, 다른 툴로 옮겨타거나, 직접적인 데이터 확인을 하려 할 경우)
가독성이 떨어집니다.
어떤게 최근의 완성된 데이터인지를 확인하기가 어렵다는 말이죠.
기존의 테더툴즈의 완성된 소스를 generate하는 부분을 통하지 않고는..
또한 테더툴즈 를 업그레이드 할 경우, 특히 저 (1)부분을 업데이트 해야할 경우,
개발자에게 막대한 부담감이 가중될 것입니다. 워낙 조심스러워야 하는 부분이거든요..

하지만, 데이터를 버전별로 하나의 화일에 저장하게 되면,
- 일반적인 작업에 CPU리소스 점유율을 낮출 수 있습니다.
  보기/수정하기 작업이 버전간의 차이를 확인하는 작업보다 많을 것입니다.
  그렇기에, 이와같이 저장을 하게되면, 보기/수정하기 작업에 서버의 리소스 점유율을 낮출 수 있고,
  다만 버전간의 차이를 확인하는 작업 시에만, 약간의(diff를 계산하기 위한) 리소스 점유율을 보일 것입니다.
  그리고, 최근 버전이 화일의 앞부분에 위치하기 때문에,
  해당화일에서 보기/수정하기 작업을 위해 최근 버전의 데이터를 뽑아내는데 서버의 CPU리소스를 낮출 수 있을거라 보입니다.
- 데이터 유지&관리 가 더욱 쉽습니다.
  버전업이나 툴 갈아타기 등을 처리하는데, 개인이나 개발자 모두  쉽게 접근할 수 있습니다.
  (온전한 데이터를 개발자 혹은 개인이 직접 보고 관리할 수 있기 때문에...)
  이는 테더소스의 유지 관리 및, 개발 위임시에도 유리하게 작용할 것입니다.
  혹은, danew님 처럼, 개인적으로 소스에 접근해서 수정을 하는 경우에도,
  직관적으로 작업을 하면 되기 때문에 쉽게 할 수 있겠죠..
- 마지막으로, 요즘에 들어서 데이터의 크기를 많이 차지하는 것은, 멀티미디어 자료 입니다.
  개인 사용자의 텍스트 정보의 사이즈를 줄이기 위해, 정보를 복잡하게 처리할 필요가 있을지는 좀 의문입니다.
  간단한 그림파일을 올리는것 만으로도, 웬만큼 긴 텍스트 보다 더욱 많은 데이터 크기를 가집니다.
  더구나, 요즘에는 그림파일 뿐 만 아니라 음성&동영상 자료를 올리는 경향이 많아지고 있죠.
  굳이 텍스트 데이터의 크기에 인색할 필요는 없으리라 봅니다.
  물론 텍스트 정보가 화일로 기록되는게 아니라 DB로 처리된다고 하더라도,
  유저가 새로운 버전으로 저장할 지를 체크할 수 있는 옵션을 주게되기 때문에,
  유저가 자신의 DB크기를 조절 할 수 있을 것입니다.
추가로, 수정작업을 할 때에, 수정을 한 부분이 얼마 되지 않으면, 기존의 버전에 덮어쓸 것인지를 메세지로 보내 확인하고, 아니면 새로운 버전으로 저장을 하도록 하는 것도, 유저인터페이스와 사용상의 편리함이 있을 듯 하군요...

저 역시 프로그래머 입니다만,
이런 웹프로그램쪽에는 경험이 없기에,
danew님처럼 실제 위키에서 어떤식으로 데이터를 처리한다 까지는 알지 못합니다.
다만, 간단히 생각해 봤을때, 이렇게 저장하는게, 유지&관리&확장성 등에서 낫다고 보였기 때문에 이렇게 생각한 거구요..
물론 wikipedia와 같은 대형 wiki사이트 혹은 제가 사용하는 pbwiki와 같은 상용 wiki사이트의 경우,
정말 많은 사람들이 위키페이지를 만들고 수정하고 하기 때문에,
danew의 의견과 같이 diff를 이용해서 하드리소스를 줄이려 할 것이라고 보여집니다.
하지만, 그와 동시에, CPU 리소스 점유율을 줄이기 위해, 일종의 cache 기능을 하는 부분이 있을 것으로 생각됩니다.
(일종의 paging방식처럼, 참조율이 높은 페이지에 대해서는 backup하고 있다가, 페이지를 생성하지 않고, 바로 뿌려주는...)
이런기능이 일반 개인이 홈페이지에까지 필요하다고는 보지 않구요..
^^

개인적인 생각이었습니다.
암튼, 다른 위키사이트에 접속해서, 개인정보와 데이터를 관리하고 있는 저로서는
(protection과 유지의 편리함 등 때문에..)
이 테더쪽에서 위키의 기능을 좀 통폐합 해 준다면...
정말 편하고, 많은 유저를 끌어모을 수 있지 않을까 합니다.

PS:
습관적으로 글을 올리면, 글을 길게 적는 면이 있습니다.
에구궁, 너무 읽기 불편하게 하는건 아닌가 모르겠네요...

htna (2006-08-06 01:08:39)에 의해 마지막으로 수정

제가 너무 짧게 적어서 전달이 안 된 부분이 있는 것 같습니다.
'최종본만 전체 텍스트로 저장하고 구버전들은 diff로 보관하는 것'입니다.
그리고 최총본은 현행 태터에서 포스트 본문에 해당합니다.

한편 태터에 기본 포함이 되면 좋겠지만 가능하면 가볍게 가려는 태터의 성향상 현실적으로 플러그인 형태가 되겠죠. 그렇다면 플러그인을 끄거나 삭제했을 때도 큰 문제가 없어야 하는데 각 버전을 한 데 모아서 저장하면 그게 곤란하게 되지 않을런지요.

근데 이거 지원하려면 그냥 위키쓰면서 그 위키의 블로그 모드를 쓰는게 훨씬 좋은 것 아닌가요?

모니위키나 모인모인은 블로그 모드도 있었던 것 같은데;;;