]]>말씀하신 서식 기능은 텍스트큐브에는 이미 들어있구요, 도메인은 /tc 가 기본입니다^^ 작성중인 글의 문제는 고민을 많이 했는데, 텍스트큐브에는 비공개 카테고리 기능이 있기 때문에 작성중인 글을 저장하는 카테고리를 만들어서 쓸 수 있습니다. 이걸 기본으로 지원할 지는 조금 더 생각이 필요할 것 같습니다.
역시 문제는 textcube.com에 적용되지 않고 있는 것이었나요?ㅜㅜ
그나저나 티켓 쌓인 것을 보니 엄청나네요... 일주일동안 앓아 누웠다가 오랜만에 웹을 제대로 접속하고 나니, 한숨이.. 아이고;
건강하세요. 그래야 원하는 것을 뭐든 많이 할 수 있잖아요. ^^
]]>글의 종류에는 서식이 추가되어야 할 것 같고, 그에 따라서 포스트에는 상속 개념이 있어야 할 것 같습니다. (시리즈물 포스팅할 때 요긴하겠죠.) Tistory에 서식기능이 있는데, 그 서식기능엔 입력할 수 있는 요소의 제한이 너무 많습니다. 제가 보기엔 일반 포스트와 거의 똑같이 저장하고(예를 들어 제목-이건 서식제목이 되겠죠-, 카테고리, 태그, 본문, 첨부화일, 위치로그 등등), 이를 불러와서 수정할 수 있도록 만드는 것이 좋다고 생각합니다. 한 마디로 일반 포스트와 똑같은데 복사돼서 새로운 포스트를 쓸 수 있는 배경으로 사용하도록 해주는 정도의 기능이랄까요? Tistory의 서식 기능은 너무나 많은 제한을 가한 덕분에 쓸모없는 기능이 됐다고 생각합니다.
그리고 작성중인 글에 대한 분류를 추가해야 할 것 같습니다. 뭐 다들 느끼시겠지만 작성중인 글(비공개)와 작성이 끝난 글(비공개)가 나눠지는데, 현재는 이들이 혼재해 보이고 있습니다. 글의 개수가 백 개, 이백 개 정도의 수준이라면 괜찮은데, 천 개를 넘어가 수천 개가 되면 공개하려다가 잊은 것이나 작성중인 것을 못 찾아서 사실상 관리가 힘들어지죠. 만 개가 된다면 비공개글 자체가 최소 수백 개가 될텐데, 여기서 자신이 원하는 글 찾는 것도 한 가지 일이 됩니다.
팀블로그 운영을 위한 사용자 설정도 백업해야 할 것이라고 생각됩니다.
아... 그리고 예전에도 한 번 건의했던 것인데, 백업할 때 자기 블로그 내에서의 링크는 자기 블로그 도메인 부분을 그것를 뜻하는 표시로 대체하는 것이 좋을 것 같습니다. 그리고 ("http://abc.abc.ttxml/1234" 라는 링크가 존재한다면 "myblogdomain/1234" 같은 형식으로요.)
ps. 여담하자면....
TT를 설치할 때 "도메인/tt" 형식으로 기본설정되게 되어있는 것 같은데, 이 거 좀 바꿔야 한다고 생각합니다. TT 부분만 일부러 찾아다니는 중국 IP도 있다고 하고, Tistory나 Textcube.com과의 연계에서도 문제가 발생할 수 있으니까요. (tt를 없앨 수 있다곤 하지만 비IT인에게는 그림의 떡....)ps. 또다른 여담이지만 TNF의 입력창좀 넓혀주세요. ㅜㅜ
말씀하신 서식 기능은 텍스트큐브에는 이미 들어있구요, 도메인은 /tc 가 기본입니다^^ 작성중인 글의 문제는 고민을 많이 했는데, 텍스트큐브에는 비공개 카테고리 기능이 있기 때문에 작성중인 글을 저장하는 카테고리를 만들어서 쓸 수 있습니다. 이걸 기본으로 지원할 지는 조금 더 생각이 필요할 것 같습니다.
그나저나 티켓 쌓인 것을 보니 엄청나네요... 일주일동안 앓아 누웠다가 오랜만에 웹을 제대로 접속하고 나니, 한숨이.. 아이고;
]]>그리고 작성중인 글에 대한 분류를 추가해야 할 것 같습니다. 뭐 다들 느끼시겠지만 작성중인 글(비공개)와 작성이 끝난 글(비공개)가 나눠지는데, 현재는 이들이 혼재해 보이고 있습니다. 글의 개수가 백 개, 이백 개 정도의 수준이라면 괜찮은데, 천 개를 넘어가 수천 개가 되면 공개하려다가 잊은 것이나 작성중인 것을 못 찾아서 사실상 관리가 힘들어지죠. 만 개가 된다면 비공개글 자체가 최소 수백 개가 될텐데, 여기서 자신이 원하는 글 찾는 것도 한 가지 일이 됩니다.
팀블로그 운영을 위한 사용자 설정도 백업해야 할 것이라고 생각됩니다.
아... 그리고 예전에도 한 번 건의했던 것인데, 백업할 때 자기 블로그 내에서의 링크는 자기 블로그 도메인 부분을 그것를 뜻하는 표시로 대체하는 것이 좋을 것 같습니다. 그리고 ("http://abc.abc.ttxml/1234" 라는 링크가 존재한다면 "myblogdomain/1234" 같은 형식으로요.)
ps. 여담하자면....
TT를 설치할 때 "도메인/tt" 형식으로 기본설정되게 되어있는 것 같은데, 이 거 좀 바꿔야 한다고 생각합니다. TT 부분만 일부러 찾아다니는 중국 IP도 있다고 하고, Tistory나 Textcube.com과의 연계에서도 문제가 발생할 수 있으니까요. (tt를 없앨 수 있다곤 하지만 비IT인에게는 그림의 떡....)
ps. 또다른 여담이지만 TNF의 입력창좀 넓혀주세요. ㅜㅜ
]]>생각나서 한번 binary-to-text 인코딩 중 효율이 괜찮은 것이 어떤 것들이 있나 찾아봤습니다. (현재는 첨부파일을 TTXML에 넣기 위해서 base-64 인코딩을 사용하고 있죠)
yEnc가 알려진 것중 효율은 가장 좋으나 여러 비판과 논란이 많았고, ascii85라는 대안을 하나 찾았습니다. 4바이트 데이터가 5바이트로 변환되므로 용량 증가 25% 정도이며, 이는 base-64의 30~40%보다는 좀더 효율적입니다.
물론 어차피 대용량 백업 파일의 경우 gzip/zip 등으로 묶는 것이 가장 좋겠지만, 이미지나 첨부파일이 많은 경우 base64가 아닌 다른 binary-to-text 인코딩 알고리즘을 사용함으로써 조금이나마 성능 향상을 꾀할 수 있지 않을까 합니다.
다른 분들 의견은 어떠신가요?
ps. 단점은 php에서 기본 제공하지 않기 때문에 php 코드로 구현된 것을 가져다 써야 하는데 용량에서 이득을 보는 대신 성능에서 손해를 볼 가능성도 있습니다.
음, 기본 제공되지 않는다는 점이 마음에 걸리네요. 아직 다양하게 사용되고 있는 것도 아닌거 같구요.
약 5%~15%의 차이라면 전 굳이 변경할 필요가 있을까 싶습니다.
]]>yEnc가 알려진 것중 효율은 가장 좋으나 여러 비판과 논란이 많았고, ascii85라는 대안을 하나 찾았습니다. 4바이트 데이터가 5바이트로 변환되므로 용량 증가 25% 정도이며, 이는 base-64의 30~40%보다는 좀더 효율적입니다.
물론 어차피 대용량 백업 파일의 경우 gzip/zip 등으로 묶는 것이 가장 좋겠지만, 이미지나 첨부파일이 많은 경우 base64가 아닌 다른 binary-to-text 인코딩 알고리즘을 사용함으로써 조금이나마 성능 향상을 꾀할 수 있지 않을까 합니다.
다른 분들 의견은 어떠신가요?
ps. 단점은 php에서 기본 제공하지 않기 때문에 php 코드로 구현된 것을 가져다 써야 하는데 용량에서 이득을 보는 대신 성능에서 손해를 볼 가능성도 있습니다.
]]>]]>top-level element를 blog 대신 ttxml과 같은 범용적인 이름으로 바꾸고, 여러 필드들 중 "꼭 필요한" 것과 그렇지 않은 것들을 분리해서 확장 필드로 넘겨버려야 할 것 같습니다.
사용자 정보에서 ID, 암호 정도만 필수로 남기고 이메일 주소, 가입 날짜, 생년월일, 자기소개 등은 다 확장필드로 해야 되지 않을까요. (권한 부분은 별도로 담아야겠죠. 이 부분을 role-based로 할 것인지 level 방식으로 할 것인지 또 의견 차이가 있긴 하겠습니다만 어떤 것이 가장 범용적일까요?)
물론, 확장 필드로 만들더라도, ttxml의 documentation에서 기본적인 것들(위에서 예로 든 이메일주소, 가입 날짜 등)은 type 등의 설명을 넣어줘야 할 겁니다.
아니면 확장 필드의 경우 attribute에 미리 정의된 type 정보를 적게 하는 것도 방법이겠군요.
type="date"
type="integer"
content-type="text/plain"
content-type="application/xml+rss"
encoding="base-64"
...
뭐 이런 식은 어떨런지요.
]]><post>
<id>1</id>
<title>글제목</title>
<ext:email>iam@laziel.com</ext:email>
</post>
XML의 장점 중 하나가 확장이 용이한건데, 충분히 활용해야죠 
inureyes 작성:...
여기 하나 추가된다면 글간의 연관성을 보여주는 <related>필드가 될텐데, 이 경우 퍼머링크 기준으로 쓰는게 나을지 id를 기준으로 쓰는게 나을지 고민해 보아야 할 듯 합니다. 퍼머링크가 없는 경우를 위해 id가 적당하기는 한데, 그 경우 incremental backup등을 어떻게 처리할 수 있을지가 문제가 되는군요.음. incremental backup과 같은 기능을 생각해봐야겠군요. 어허...
그렇다면 현재의 모습 - nested element를 활용 - 을 사용할 수 있을까요?
...
가장 간단한 방법으로는 DB에 modified된 시간과 댓글의 시간이 기록되므로, 마지막 백업 시점보다 나중에 기록된 것이 있으면 그 부분을 포스트 통째로 다시 백업하는 방법이 있겠습니다. 이 방법이 구현에 있어서 가장 간단하기는 하겠습니다. 단, 복원시에 현재는 초기화 후 집어넣거나, 현재 들어있는 상태에 추가적으로 데이터를 더하거나 하는 두가지 방법 뿐인데, 이 경우에는 그 외의 경우도 고려해야 되겠지요.
단점이라면, 역시 효율이 떨어진다는 점을 들 수 있을 것 같습니다.
...
여기 하나 추가된다면 글간의 연관성을 보여주는 <related>필드가 될텐데, 이 경우 퍼머링크 기준으로 쓰는게 나을지 id를 기준으로 쓰는게 나을지 고민해 보아야 할 듯 합니다. 퍼머링크가 없는 경우를 위해 id가 적당하기는 한데, 그 경우 incremental backup등을 어떻게 처리할 수 있을지가 문제가 되는군요.
음. incremental backup과 같은 기능을 생각해봐야겠군요. 어허...
그렇다면 현재의 모습 - nested element를 활용 - 을 사용할 수 있을까요?
<post>
....
<comment>...</comment>
</post>post는 백업이 되었는데, 그 이후에 댓글이 달렸다면? 간단하지 않군요 
ttxml이 갖춰야 할 기능적인 요건을 먼저 정리를 해볼 필요도 있겠습니다.
백업 이런 건 어떨까요?(DB 관리기능 제안창구): http://forum.tattersite.com/ko/viewtopic.php?id=2539
위 글에 나오는 것 처럼, 어떤 형태로든 "부분 백업", "증분 백업" 이 가능해야 한다거나.. 말입니다.
]]>