빨리 작업해야해서  잘 하시는분이 좀 도와주셨으면 좋겠네요.

물론 능력에 따라 수고비는 당연히 있습니다.

우선 문자로 살고계신곳 알려주시고, 샘플을 볼수있는 주소알려주셨으면 좋겠네요.

016-208-0788

제 개인적인 의견 몇자 적어봅니다.

* 입력단
   * OpenSearch 스펙을 활용한 검색창 입력 방식은 IE, FF 에서만 지원된다는 한계가 있을듯 싶습니다. 입력 창구를 IM, SMS, 별도 client 등으로 다양화 하면 좋을듯 싶습니다.

* 출력단
   * 사이드바 위젯으로 line 위젯이 추가되면 좋을듯 싶습니다.

구체적인 설치 가이드는 http://daybreaker.springnote.com/pages/1723022.xhtml 이곳을 참고하시기 바랍니다.

ps. 이거 공지사항으로 옮겨야 될까요? =3=3

변환되기 전:

<div class="plugin-replacer $customClass" ttml:handler="$pluginName" ttml:attr1="value1" ...>
  <div class="plugin-content">$originalContent</div>
  <div class="plugin-fallback">$fallbackMsg</div>
</div>

위에서 ttml: 네임스페이스를 가지는 것은 플러그인에게 associative array 형태로 전달. 이것만으로 충분하다면 .plugin-content 영역은 넣지 않을 수도 있음.

변환된 후:

<div class="plugin-replaced $customClass" id="$customID">$processedContent</div>

또는

<div class="plugin-fallback">$fallbackMsg</div>

이런 형태는 어떨까요?

위 주소에서 보시면 되며, 앞으로 작업 진행에 따라 비정기적으로 갱신될 것입니다. 그동안 표준화기구에서 자체적으로 진행해오고 있었으나 다른 분들의 세세한 의견 수렴을 통해 좀더 다듬고자 함이니 많은 의견 부탁드립니다.
이와 함께 다음 티스토리, 구글 텍스트큐브닷컴 팀과 계속 의견 조율이 진행될 것이며 아직 draft인만큼 크고 작은 변화가 있을 수 있습니다.

주요 특징 :
* 기존 치환자는 모두 사라집니다.
* skin.html의 중요도가 대폭 감소하고, 대신 css selector로 스킨 디자인을 정의하게 됩니다.
* 세부 구성 요소(예: 댓글입력폼)의 html 요소는 각 서비스 주체가 알아서 렌더링하므로 이에 대한 세밀한 제어는 안 됩니다. 대신 스킨의 범용성을 높일 수 있습니다. (심지어 텍스트큐브 계열이 아닌 툴에서도 사용할 수 있음)

텍스트큐브에서는 하위호환성을 위해 기존의 스킨 규격과 이 스킨 규격을 동시에 지원할 예정입니다.

ps. PDF로 만들어서 올리려고 했으나 ul/ol 항목의 indent 때문에 짤리는 부분이 많아 publish 후 링크했습니다.

현재는 dojo 0.4 버전과 자체적으로 만든 Eolin Application Framework (EAF)를 사용하고 있는데, dojo가 1.x로 넘어오면서 API 구조가 많이 변경되었기 때문에 새 버전에 대응하려면 어차피 전면적인 코드 재작성이 필요한 상황입니다.

그리고 현재 개발팀에서 dojo보다는 prototype이나 mootools 등 다른 프레임워크를 더 선호하시는 분들도 있어서, 앞으로 보다 원활한 개발을 진행하기 위해 어떤 자바스크립트 프레임워크를 선택할지 논의하기로 하였습니다.

우선 고려해야 할 조건으로는,
* 용량이 작고 브라우저의 속도에 영향을 가급적 주지 않아야 한다.
* 버전업에 따른 하위 호환성이 잘 지켜져야 한다.
* 짧고 직관적인 API가 제공되어야 한다.
* 향후 오랜시간 동안 망하지 않고 유지·보수가 잘 되어야 한다.
* 애니메이션 등 이펙트가 지원되면 좋다. (선택)
정도가 있겠습니다.

우선 물망에 오른 것은 mootools와 jQuery인데, mootools가 가볍고 빠르긴 하지만 1.1 -> 1.2 버전업 과정에서 하위호환성이 깨지는 문제가 있었고, jQuery는 아직 팀내에서 많이 써서 익숙해진 사람은 별로 없으나 마이크로소프트의 지원으로 개발층이 커질 것으로 기대된다는 장점이 있습니다. (사실 처음에 dojo를 선택한 것도 IBM이 밀어준다는 것이었습니다) 이외에 prototype이 가장 널리 알려져있고 대부분 어느 정도 익숙하긴 하지만 크기와 속도 문제로 후보에서 잠정 제외되었습니다.

자바스크립트 프레임워크가 선정되면 기능 충돌을 막기 위해 우선 EAF는 해당 프레임워크를 이용해 재구현하게 되어 일종의 alias 성격을 띠게 됩니다. 또한 위지윅 에디터 등 많은 부분의 코드가 재작성될 것입니다.

아무튼 이 사안에 대해 포럼에서 좀더 폭넓게 의견을 수렴해 논의하기로 하였으니 많은 의견 부탁드립니다.

생각 같아서는 PHP4도 확 버리고 PHP5 전용으로 하고 싶지만(.....이렇게 하면 코드를 훨씬 깔끔하게 할 수 있습니다) 이건 좀 무리겠지요?;;;
DB 모듈을 잘만 짜면 MySQL 3.x 지원도 어찌 가능할 것 같긴 한데 현실적으로 해야 되나 의문입니다. 호스팅들 중에 아직도 MySQL 3.x 쓰는 곳이 있나요?;

왜이렇게 멍청한 짓을 하였는지 모르겠습니다만 base64 encoding을 xml rpc 레이어가 아닌 어플레이케이션 레이어에서 한 후  스트링으로 보내는 만행이 표준이군요. 허나 지금까지 프로그램들이 잘 동작해 온것을 보면 당연히 바이너리 파일은 base64 타입으로 자동적으로 보내져 온것으로 보이고;;; (아무튼 이동네 api들은 좀 웃기는)

아무튼 표준적으로는 string으로 올때 이것을 base64_decode 하는 것이 정상일것 같습니다만, base64로 인코딩 되어 온것을 지원 안할수도 없고. 문제는 xml-rpc 레이어에서 자동으로 처리되는지라 api 처리 루틴에서 이게 string으로 왔는지 base64로 왔는지 알 방법이 없다는 것.

textcube 전 버전과 tistory가 이 버그를 가지고 있군요.

아이디어 생각나시는분?

http://www.tistory.com/forum/viewtopic.php?id=1129
http://www.cybervill.net/entry/루비에서-티스토리로의-글-포스팅

우선 기본스킨과 추가된 1up님의 스킨에 적용된 사이즈가 어딘가.. 어색합니다. 최소 폭 190px 를 기준으로 삼을때 여유공간이 적은 것 같습니다. 심볼이 기존 스킨에 커 보이는 어색함은 더 작아지는데 무리가 있는 듯 합니다.

윈도우 심볼을 연상하게 하는 색동 심볼이 매우 화려하고 인지도도 높습니다만 이 심볼은 크기가 큰 형태에서는 효과적이나 작은 형태에서는 표현이 미미하고 제한적입니다. 작아지면서 색상이 겹치어 뚜렷하게 보일수 없는것과 눈에 띄는 색과 반대의 색들이 작아질수록 형태의 함몰현상이 나타나기도합니다. 최소 사이즈는 아니어도 150 x 30 정도에서 어느정도 뚜렷한 상태가 되어야 할 것 같습니다.

로고체의 Textcube 역시 나루체 종류가 심플하고 단아해 보이나 심볼이 갖은 굵기에 비해 얇아서 심볼의 크기가 작아질 때 더 얇아지는 것이 점점 흐릿해집니다.

지금의 디자인은 새 도약을 위한 좋은 상징이 되었습니다. 테터캠프 때 받은 티셔츠나 포스터 처럼.. 캠페인 혹은 이벤트 심볼로 효과적입니다. 하지만 이제 정식버전에 앞서서 평생 얼굴이 될 실험적 조합들이 나와야 할 때인 것 같습니다. 브랜드로 정착하기에 어떤지? ;;; 요

ps.
다행이도 이전 이름의 이니셜 T가 같다는 것이죠 이전 T 심볼과 함께 진화해도 좋을 것 같다는 생각.. 연대성도 생기고 정체성도 뚜렷해지지 않겠나 하는... 생각

바캠프처럼 진행된 1회 태터캠프와 강의 시간 같았던 2회 태터캠프에서 얻은 교훈을 통해서 3회의 경우는 예전 오픈하우스 형식+바캠프+이벤트로 만들어지는 재미있는 자리로 한 번 펼쳐보면 어떨까요? 2회때 뒷풀이 저녁때 들은 부분 -사실 이런 대화(저녁식사 하면서 나눈 대화였죠)가 듣고 싶어서 태터캠프에 오셨었다는- 이 아직 기억에 남습니다.

8월 초쯤 되면 휴가철이기도 하니 7월 말이 어떨까 싶습니다. 다들 어떻게 생각하시는지요? 1,2회로 단련이 되었으니 이제 우리도 좀 병아리 티는 벗고 재미있는 자리를 만들 수 있을 것 같기도 합니다.

참석이 가능 하실지, 준비를 도우실 수 있을지 등등을 한 번 댓글로 나누어 보죠

ttxml에 대해서 궁금한 것을 몇 개 올립니다.

아래는 ttxml 검색했을 때 관련글입니다.
백업파일 포멧의 문서화는? - http://forum.tattersite.com/ko/viewtopic.php?id=1038
wp2tt가 대충 만들어져갑니다.. - http://forum.tattersite.com/ko/viewtopic.php?id=1256
(...ttxml 이름은 이렇게 굳어져 버린건가요 -_-; 허허허)

ttxml이 태터툴즈 프로젝트의 key가 되는데, 스키마를 정의하고 이를 강제해야 할 것이라고 봅니다. 그런데 정작 제대로 작성된 xsd는 없군요.

wp2tt를 만들 당시에 문서화를 하다가 만들어놓은 게 있긴 한데, 태터툴즈 소스를 보고 한 것이 아니라 백업 결과물을 보고 한 것이라 불완전합니다. 빠진 것도 좀 있고요.

보시려면 - http://dev.tattersite.com/browser/wp2tt/ttxml.xsd

ttxml의 version이 어떻게 진행되고 있는지도 잘 모르겠고,  ttxml의 구조상 지원하기 어려울 듯한 기능들에 대해서도 논의가 어떻게 진행되었는지 잘 모르겠습니다. 추가를 해야 가능한 것도 있고, 아니면 불가능한 것도 있을 텐데요.

ttxml과 관련된 이야기가 어떻게 진행되었는지 알려주시면 감사하겠습니다

덧. 어느 게시판에 올려야 할지 몰라서 -_- 일단 잡담 게시판에 올립니다.

서울이 아닌 곳에서 열었을 때 얼마나 참석하실 수 있는지, 얼마나 많이 함께 하실 수 있는지, 또는 사는 곳에서 직접 여실 분들은 얼마나 있는지 알아보고 추진해 보는 것이 어떨까 합니다.