몇가지 말씀하신 부분에 대해 답해봅니다.
1. MT 트랙백 표준확장에 대해
1) MT 트랙백 규격은 현재 버전 1.2입니다. (2004년 8월 1일)
2) encoding은 트랙백 보낼 시에 선언할 수 있습니다. HTTP의 Content-type에 그 내용을 적어야 합니다.
[code]
POST http://www.example.com/trackback/5
Content-Type: application/x-www-form-urlencoded; charset=utf-8
title=Foo+Bar&url=http://www.bar.com/&excerpt=My+Excerpt&blog_name=Foo[/code]
원래는 이렇게 보내져온 것을 받으면 그에 따라 수신처에서 알아서 풀어서 해독하고 하면 될 일입니다. 송신처에서 수신처의
인코딩타입따위를 알아야할 필요는 없습니다. 물론 국내의 서비스 및 도구 개발자들이 charset이나 encoding에 무지한
관계로 이런 기능을 활용못한 것이지요. 국내의 개발자들이 멍청해서 EUC-KR 전용이 되어버린 서비스를 배려하기 위한 꼼수등은
필요없습니다. 필요한 것은 욕설 한바가지 뿐이지요.
3) Retrieving TrackBack Pings은 deprecated되었습니다. 표준규격도 아니고, 그 효용도 없다고
판단되어서라지요. 그러나 Ver 2.0에서는 다른 형태로 이 기능을 지원할 예정이라고 합니다. 개인적으로는 별 필요없다고
생각합니다. 트랙백 RDF와 DB저장내용을 잘 참조하면 이 스펙이 없어도 얼마든지 구현가능하니까요.
4) 트랙백의 수정, 삭제는 확실히 미진한 기능이긴 합니다. Ver 2.0에서는 개선될 지도 모르겠군요. 미리보기는 오버라고 생각합니다. 그건 트랙백 규격의 문제가 아니라 사용하는 서비스 도구의 문제겠지요.
2. 트랙백 자동발견 및 자동전송기능의 중복은 트랙백 규격의 문제가 아니라 역시 도구의 문제입니다. 어디로 트랙백을 보냈는지 DB에 저장해두고 중복된 곳으로 보내지 않게 구현하면 될 일이지요.
3. 상대방에게 얼마나 표시될 지 모른다…는 것은 사실상 의미없는 불만입니다. 왜냐하면, 받은 트랙백의 표시방법은 수신처의
마음이거든요. 트랙백을 받고도 전혀 표시안할 수도 있고, 필요하다면 트랙백 받은 주소로 봇을 보내어 페이지를 통째로 긁어와서
표시해줄 수도 있습니다. 요컨데, 트랙백이란 “댓글”이 아니라 “ping”이니까요. 신호를 전달해줄 뿐이지, 그 신호를 어떻게
쓰고, 어떻게 해석할 지는 수신처의 소관이지요.
4. 따라서 보낸 트랙백의 수정, 삭제는 ping이라는 관점에서 본다면 넌센스에 가깝습니다. 다시 말씀드리지만, 트랙백은
“댓글”이 아니라 “ping”입니다. 글이 publish된 시점에 수신처로 ping신호를 한번 보내기. 그걸로 끝입니다. 이미
전에 보낸 ping신호를 어떻게 수정하고 삭제하겠습니까.
그러나 만약 필요하다면 이것은 서비스 차원에서 해결할 방법은 있습니다. 예를 들어 이전에 받았던 트랙백과 같은 title로 같은
도메인에서 새로 트랙백이 보내진다면, 그것을 “수정신호”로 인식해서 이전에 받았던 트랙백기록을 새 트랙백 기록으로 교체하기 같은
아이디어를 구현할 수 있겠죠. (거듭 말씀드리지만, 이 역시 트랙백 규격의 문제는 아닙니다.)
5. excerpt 문제는 국내의 블로그 서비스 개발자들에게 비난을 돌리세요. 트랙백의 문제가 아니죠. excerpt 필드가 없어서 RSS에서도 description문제가 발생하지 않았습니까.
6. excerpt의 길이문제도 마찬가지이긴 한데, 한가지 문제가 있는 것이, 원래 트랙백은 HTTP GET을 염두에 두고
작성되었습니다. 따라서 전달할 수 있는 데이터의 byte 제한이 있었습니다. 물론 지금은 HTTP POST로 형식이
바뀌었습니다. 길이 제한은 없어졌으나, 그것을 어떤 식으로 표시할 지는 송신처든 수신처든 나름 재량입니다.
7. SixApart사는 그다지 놀고 있지 않습니다. 현재에도 트랙백 규격 2.0을 위해 개발자 포럼등에서 활발하게 논의되고 있습니다. 
0개의 댓글