mearie four point zero

long term to-do list에서 했던 얘기를 구체적으로 해 보자. due date는 (내 맘대로) 2012년 런던 올림픽 시작할 때까지.

가장 큰 방향

계층 구조를 버린다. 정확히 두 개의 축, 시간축과 주제축만을 반영한다. 다년간의 삽질을 통해 계층 구조가 컨텐츠 관리에 전혀 도움이 되지 않는 걸 깨달았으므로, 과감히 메뉴를 없애는 쪽으로 간다. 첫 페이지는 가장 최근에 올라 온, minor하지 않은 변경 사항을 그대로 보여 준다. (실제로 어떻게 하는지는 뒤에서)

웹 인터페이스를 이번에는 기필코 만든다. ikiwiki 스타일이면 충분하다(그러나 ikiwiki를 써 본 경험으로는 이걸 cgi로 하는 건 자살행위였으니 다른 방법을 고민하자). 웹에서 수정한 뒤에 즉각 hg에 커밋을 할 수 있어야 한다. 커밋 할 때 metadata를 입력할 수 있어야 하며, 이 metadata가 실제 표시에 영향을 미쳐야 한다(당장 첫 페이지에 변경 사항을 얼마나 보여 줘야 할지 알려면 metadata가 필요하다). 물론 콘솔로 변경하는 것도 응당 고려해야 한다(따라서 metadata 설계를 잘 해야 한다). 또한 아래 설계에 따르면 20yy/mm/ URL에서 세부적인 URL로 옮겨 가는 것이 흔할 것 같아 보이는데(특히 text/로…), 이 부분도 수정시 한 번에 바로 할 수 있어야 한다.

URL 구조도 단순화한다. about/(“대하여”), projects/*/(커다란 소프트웨어, hg.mearie.org과 연동), text/(document/였던 것들 + 시간축에서 별 의미를 지니지 않는 것들이 몇 번 수정된 뒤에 여기로 옮겨 옴), pub/(내부 경로, 바깥에 publish할 때는 pub.mearie.org으로 매핑)를 제외한 모든 내용은 20yy/mm/ 아래로 재분류한다. 선술한 세 개의 패쓰는 그 자체로 하나의 위키처럼 생각하도록 한다(따라서 internal link는 모두 그 안에서만 논다). 현재 뇌에 있는 내용 중 예를 들어 나루에 관련된 내용은 projects/naru/ 하위로 옮겨 가고, PyFunge에 관련된 내용은 projects/pyfunge/ 아래로 모두 옮긴다. 이런 스킴으로 계속 쓰다 보면 20yy/mm/에 있던 내용이 projects/*/로 옮겨갈 수도 있는데 (예를 들어 rewiki 같은 걸 실제로 구현한다고 치면) 이 경우 gracefully redirect시킬 수 있다.

컨텐츠 도메인은 네 개로 정리한다. mearie.org (everything else), pub.mearie.org (풉;, 실제로는 한 저장소로 통합), hg.mearie.org (이 쪽도 인터페이스 고칠 수 있으면 고치고 싶다), cosmic.mearie.org (현재와 마찬가지로 unversioned content를 올리는 용도). 나머지 도메인은 redirection만 한다: svn.mearie.org는 드디어! 폐쇄(하고 기존 코드는 hg.mearie.org/20yy/mm/...으로 옮김), noe.mearie.orgmearie.org에 필요한 만큼 redirection, j.mearie.org도 마찬가지.

정적 웹사이트 구조는 유지하되, 컴파일러의 재량권을 높인다. 현재의 Makefile 기반 구조는 여러 이유로 한계에 달한 것 같으므로, 커스텀 스크립트를 만드는 수 밖에 없다. *.<lang>.txt는 마크다운으로, *.log는 irc 로그 quick posting으로, *.meta는 redirection/gone 등을 처리하기 위한 특수 directive로(그럼 컴파일러가 알아서 .htaccess를 생성하던지 하겠지) 뭐 그런 식으로 좀 더 매핑을 한다. 여기서 중요한 것은, 지금까지 이런 걸 구현 못 한 가장 큰 이유는 현재 working directory와 publish directory가 하나로 합쳐져 있어서(!!!!) 그런 것이다(그리고 mod_negotiation이 폭주해 주시는 덕분에 *.txt 원본 파일 서빙은 publish 쪽에서 막혀 있다). 그러니 이제는 둘을 분리해야만 한다.

r.mearie.org을 좀 더 잘 써 보자. 여러 이유로 disqus 같은 건 여전히 쓰지 않으려고 하지만, response 란을 언제고 막아 놓을 수는 없는 노릇이다. 스팸이 피곤하겠지만 뭐 어쩔 수 없고, reCAPTCHA를 쓰든지 뭔가 대강 대충 쓸 수 있는 문제를 적어 놓던지 해야지.

markdown prime을 전사적으로 적용한다. 특히 밑줄 넣으면 폭주하는 거 어떻게 해야만 한다(당장 위에서 mod_negotiation이라고 쓴 것도 escape해야 한다!). 아마도 전체 작업에서 가장 큰 비중을 차지할 것으로 보인다. 아이디어는 충분히 있는데 말이지. rewiki는 현재로서는 무리고, markdown prime에서 inclusion 기능을 강화함으로서 해결하는 쪽으로 해야 겠다.

빠른 변경이 가능하도록 한다. jmk.pe.kr의 quickposting이 가장 그럴듯하다. irc 로그 quick posting을 고려하는 것도 비슷한 이유. 정적인 도메인에 웹 인터페이스를 도입해야 하니 token 시스템을 사용하든지 뭘 도입하든지 아무튼 좀 미친 짓을 해야 할 걸로 보인다.

빠른 미러링이 가능하게 한다. r.mearie.org과 같은 커스텀 서비스를 제외하면(가만있자, 그럼 관리 인터페이스 서브도메인은 뭘로 하냐?) 나머지는 여전히 정적 페이지니까 아무 문제 없이 호스팅이 되어야 한다. 컴파일러를 완전히 교체할 생각이니 git 저장소로 export하기 이런 메뉴를 만들어 보는 게 어떻겠는가. 아 이왕 컴파일러 고칠 거면 css/js minification 같은 것도 이제 좀 해야 겠다.


ikiwiki를 씁니다.
마지막 수정