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

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

각각의 개인의 입장에서는 나와 있는 툴을 선택하는 것이지만, 툴을 중심에 놓고 생각할 때는 위키 방식을 지원하는 것으로 더 다양한 사용성을 부가하게 되는 것이 아닐까요.
블로그에 위키가 상충된다고 생각하지 않습니다. 없는 부분을 더해준다고 생각합니다. 이를테면 자신의 글에 하이퍼링크를 손쉽게 걸 수 있다는 점은 글간의 연결성과 짜임새를 향상시킬 것이고 전체적인 포스팅의 일관성을 촉진할 수도 있지요.

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

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

비슷하게 볼 수 있을 수도 있습니다.
모니위키나 모인모인은 위키에서 블로그 형태를 지원하는 거죠.
그러다보니, 위키의 테두리에서 벗어나기 힘듭니다.
실제로, 플러그인 등이 있습니다만, 지금의 테더처럼, 확장성과 블로그로서의 기능이 충분히 따라가는지는 모르겠군요..
또한 위키위키 (모인모인은 써보지 않아서 모르곘습니다만..)의 경우, 위키베이스 이다보니.
아무래도 초기 접근성이 좀 떨어집니다.
정보가 산만하게 퍼져있고, 영어기반이라 찾아보는데 신경이 쓰이고, 내부적인 세세한 부분을 좀 알아야 설정이 가능할 듯 하더라구요...
더구나, 정말로 글의 접근권한을 주고 싶은데..
너무 찾아보기 어렵더군요.
결국 포기하고, 저의경우는, 상용위키면서 10M까지는 무료로 제공하고 접근권한을 주는 pbwiki로 옮겼습니다만.
또한, 위키의경우, 아무래도 모양새가 깔끔하지 않아요...

여기 테더에서 위키형태를 지원을 하길 바라는 것은,
블로그를 기본으로 사용하면서, 위키를 같이 사용할 수 있지 않을까 하는 기대죠.
위키를 사용할 정도면, 대부분 블로그도 있을 것이라 보입니다.
하지만, 저처럼, 위키따로 블로그 따로 관리하는 경우가 많지 않을까 합니다.
테더가 화려함&확장성&편리함 을 가졌고, DB로 정보를 처리하는 점과, php 기반이기에 프로그램/플러그인을 통한 확장성을 생각해보면, 위키의 기본기능으로 확장하는 것 역시 어렵지 않은것이라 생각이 들어서...

아무래도 다른 장점은, 테더의 경우, 한글기반이란것도 매우 큰 장점이지 않을까 합니다.
뭐... 결국은 테더쪽에서 어느정도, 필요한 기반사항을 제공해줘야, 위키로의 확장이 가능할까 생각이 들기는 합니다만..
^^

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

htna 작성:

diff로 데이터를 저장하게 되면,
매번 그 페이지로 html 페이지를 만들때마다,
(1) diff로 구성되어 있는 화일로부터, 온전한 화일을 만들고,
(2) 온전하게 만들어진 화일로 html 페이지를 구성
해야하는 2단계 작업으로 됩니다.

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

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

최종본만 제대로 저장하고 나머지는 diff로 저장한다..
그런 방법이 있었군요...
좋은방법인것 같습니다.
그렇담 저장형태는
"(version 3) + (diff 3 to 2) + (diff 2 to 1)"
형태로 되어야 할 듯 하군요...

플러그인으로 하기에는 몇가지 어려움이나 선결되어야 하는 문제가 있어야 하지 않을까 합니다.

우선, 소스데이터를 DB로 전달하는 과정에서 중간에 플러그인을 처리할 수 있는 부분이 있을지...
제가 테더 플로그인에 대해서 아는것은 아니지만, (추측하건데...)
DB의 자료 -> (플러그인 개입) -> html 작성
형태로 플러그인이 동작하지 않을까 생각이 듭니다.
하지만 이 경우에는
1. source -> (wiki plugin) -> DB
2. DB -> (wiki plugin) -> html
두군데에 모두 들어가야 하는데. 1번에 해당하는 플러그인 추가할 수 있는지는 모르겠습니다.

그리고, 이 문제가 없다고 하더라도, 다른 플러그인 들과의 충돌을 고려해야 할 듯 합니다.
1. source -> (wiki plugin) -> (plugin1, plugin2, ...) -> DB
2. DB -> (wiki plugin) -> (plugin1, plugin2, ...) -> html
과 같은 형태로 처리된다면 문제가 없지 않을 듯 합니다만,
1. source -> (plugin1, plugin2, ...) -> (wiki plugin) -> DB
2. DB -> (plugin1, plugin2, ...) -> (wiki plugin) -> html
와 같이 어느 하나라도 순서가 바뀌는 날에는 다른 플러그인 들과 충돌이 날 것이라 보여지는군요..
플러그인 간의 우선순위가 주어진다면,
어느정도 소화가 될 수 있을듯 합니다만...

그리고, 플러그인으로 diff와 같은 부분을 가볍게 계산할 수 있을지..
일반적으로 플러그인 모듈이면, 간단하게 부가적인 동작을 추가하는 쪽으로 생각이 됩니다.
그만큼 플러그인 자체가 가벼워야 하는게 아닌가 생각이 듭니다.
하지만, 이 경우에는 diff라는 작업이 그만큼 가볍게 느껴지지많은 않습니다.
어짜피, diff를 요구할 때만, 서버쪽에서 diff를 처리하는 과정이 들어갈 것이기에,
별 상관이 없을것으로 보여지긴 합니다만...

마지막으로, 수정&버전차이 관리 페이지를, 플러그인으로 처리가 가능한지..
"DB -> ... -> html" 과정중에는 사용자의 인터렉션이 없기에 별 문제가 없겠지만,
해당 페이지를 수정 혹은 버전차이를 보는 경우에는, 페이지 작성자의 인터렉션이 필요하기 때문에,
이러한 페이지를 플러그인으로 처리가 가능한지 모르겠군요.

원래는, 테더쪽에거 확장 혹은 위키지원을 위한 기본적인 함수를 지원하고 (DB및 버전관리 부분),
나머지 간단한 부분에 (wiki 형식의 포멧 관련) 대해서는 플러그인 쪽으로 처리하는게 낫지 않을까 생각했습니다..
플러그인으로만 처리가 가능할 수 있다면, 그 또한 좋을 듯 합니다.

diff로 데이터를 저장하게 되면,
매번 그 페이지로 html 페이지를 만들때마다,
(1) diff로 구성되어 있는 화일로부터, 온전한 화일을 만들고,
(2) 온전하게 만들어진 화일로 html 페이지를 구성
해야하는 2단계 작업으로 됩니다.

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

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

테이블'만' 빼고 구현이 되어 있어서 릴리즈 못하고 있습니다 ㅎㅎ

음..
재밌는 작업일 것 같습니다만,
아쉽게도 제가, 지랄같은걸 하고 있는 중이라,
다른걸 못하네요..
지금 하는거 마치고, 이부분 함 건드려보면 재밌으려만...

위키에서 텍스트는 저장할 때마다 불어나지만 (전통적인 방식에서는 맞춤법 수정으로 저장을 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:
습관적으로 글을 올리면, 글을 길게 적는 면이 있습니다.
에구궁, 너무 읽기 불편하게 하는건 아닌가 모르겠네요...

inureyes 작성:

ㅎㅎ 사실 위키 엔진을 이용해서 문법만을 지원하는건 개인적으로 플러그인을 만들어 사용중입니다

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

테이블'만' 빼고 구현이 되어 있어서 릴리즈 못하고 있습니다 ㅎㅎ

danew 작성:

[ ] 로 묶은 글은 그 안의 내용으로 제목 검색을 하게 하는 하이퍼링크 적용. 클릭하면 해당 제목의 포스트로 바로 이동. 해당 제목의 포스트가 없을 때는 어드민일 때 '이 제목으로 포스트 생성, 비슷한 제목의 포스트들...' 등등 출력. 그런데 이렇게 하면 부하가 줄더라도 아직 포스트가 없는 제목을 구별해서 표시할 수 없으니까 문제가 되는군요. -_-
제목 충돌이 있을 경우에는 최선의(제 생각에는 최초의) 포스트로 이동하게 하고 제목 하단에 여타 포스트들 링크를 표시(위키피디아처럼).
제목 충돌이 있을 때 포스트를 특정할 수 있도록 [] 안에서 구별 접미사같은 것도 가능하겠지만.. 문법이 복잡해지는 것도 그렇고, 가능한 제목 충돌을 피하게끔 유도하도록 일부러 제공하지 않는 편이 좋다고 생각합니다.
역링크는 포스트 제목 옆에 출력시키도록 해야겠고요.
버전관리와 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의 부하를 좀 더 덜 수 있을 듯 보입니다.

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

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

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

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

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

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

ㅎㅎ 사실 위키 엔진을 이용해서 문법만을 지원하는건 개인적으로 플러그인을 만들어 사용중입니다

[ ] 로 묶은 글은 그 안의 내용으로 제목 검색을 하게 하는 하이퍼링크 적용. 클릭하면 해당 제목의 포스트로 바로 이동. 해당 제목의 포스트가 없을 때는 어드민일 때 '이 제목으로 포스트 생성, 비슷한 제목의 포스트들...' 등등 출력. 그런데 이렇게 하면 부하가 줄더라도 아직 포스트가 없는 제목을 구별해서 표시할 수 없으니까 문제가 되는군요. -_-
제목 충돌이 있을 경우에는 최선의(제 생각에는 최초의) 포스트로 이동하게 하고 제목 하단에 여타 포스트들 링크를 표시(위키피디아처럼).
제목 충돌이 있을 때 포스트를 특정할 수 있도록 [] 안에서 구별 접미사같은 것도 가능하겠지만.. 문법이 복잡해지는 것도 그렇고, 가능한 제목 충돌을 피하게끔 유도하도록 일부러 제공하지 않는 편이 좋다고 생각합니다.
역링크는 포스트 제목 옆에 출력시키도록 해야겠고요.
버전관리와 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 작성에 어려움이 있으려나...) )
- " " (줄 맨 앞에 공백 사용시, 자동으로 블록으로 보이게 해 주는 기능)
등과 같은 몇가지 간단한 기능을 활성화 해 주면 매우 유용할 듯 보이네요..

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

개인정보 관리등에는 위키를 따라갈 것이 아직은 없다고 봅니다.
물론 테더툴즈가 블로그에 초점이 맞춰져 있는것은 사실입니다만.
위키와 같은 형태의 홈페이지 관리도 할 수 있게 하는것은 어떨까 생각합니다.

이미 데이터베이스를 이용해서 각 블로그 포스팅을 지원하고 있기에,
위키와 같이 자동 페이지 생성, 링크연결 등과 같은 일을 추가하기에..
(물론 개발자로서 노력이 들어가야 겠지만...)
불가능하지는 않다고 봅니다.
어떤면에서는 몇가지 플러그인 형식으로도 할 수 있지 않을까 생각합니다만.
물론 플러그인 형식으로 하려면, 테더툴즈 자체의 함수가/기능이(페이지 생성 & 삭제 & ...) 있어야 가능하지 않을까 생각합니다.

개인적인 자료 정리 (이력, 등...),
개인 프로젝트 관리,
개인 문서 관리,
자기소개 페이지의 다양화

등과같이, 활용할 수 있지 않을까 합니다.
저도 위키를 사용하고 있는 유저라, (pbwiki라는 것을 이용합니다. 따로 설치하기가 귀찮아서..)
위키의 편리함과, 정보접근권한의 필요성을 느끼고 있는데,
다른 위키들은 정보접근권한에 너무 무신경하더군요...

혹시,
테더툴즈에서,
위키와 같은 (비슷한 형태의) 서비스를 해 줄 수 있고 (자동 페이지 생성 & 링크 연결은 필요하다고 보구요.. 버전관리는 사용하는 사람에 따라 없어도 될 듯 하군요.. 즉, 버전관리 기능까지는 개발에 무리가 된다면 없어도...),
접근권한을 설정할 수 있게 한다면 (업데이트 허용권한(관리자만 업뎃 가능하다던지..), 보기 허용권한(어느페이지 까지는 guest가 볼 수 있고, 어느 페이지 까지는 관리자만 볼 수 있다던지..), 등...)
상당수의 위키유저 또한 테더툴즈로 끌어올 수 있지 않을까 합니다.