I want to use Trackback in Radio.
I had blogged a link to the specs from Simon Fell's post a while ago, Pingback v. Trackback. [Simon Fell], but was too busy to take a look at it.
Then today I discovered reversible through kottke through Kottke.org through Werbach through... Mark Pilgim's excellent Recommended Readings (how far Mark's cool service can take you ! Mark you ruined my workday :-)
I love the idea of reversible, a mix of webrings, wiki and newsgroup, using weblogs and trackback.
Si I need to be able to use Trackback in Radio.
I searched and searched more but the only things I found were:
There does not seem to be any trackback client implementing automatic pinging in Radio today.
I downloaded and use Simon Fell's excellent Pingback client for Radio and it works like a charm: my post about Sam Ruby's pedantic web entry automagically appeared in his comments section. Not that my comment was especially interesting. There should be an option in your client (a checkbox in Radio before publishing), to let you determine wether you want to ping back the url you post: I very often post links to my weblog to notify my readers of what I found interesting, and when i have no meaningful comments, pinging back is not necessary. Or maybe adding some attributes in a new namespace in the trackback post and RSS to specify that it is just a reference with no meaningful comments, which would let the trackbacked site discard your url, or present it in a different way (just the title). This would allow a way to distinguish between posts that represent an entry in a dioscussion and posts that are mere links.
If trackback is not enabled in Radio I'll try to do it in my spare time (there is not much of it though).
First I looked at the specs.
pingback, and trackback specs.
I wrote a summary for those of you who do not have the time to read the spec. this was useful for me in order to understand the difference, which was not very clear to me last month when I read the specs at first.
IN the description site A refers to site B in a blog post
pingback
client side:
A parsed
find a link to B
download B
look for http header X-Pingback: "B pingback server", if not parse the page for <link rel="pingback" href="B pingback server">
A makes a xml rpc call to "B pingback server" sending
pingback.ping('A', 'B')
server side
B receives the ping
B checks that B url is part of himself
B fetches A, verifies it contains B, extracts title and some content
B keeps a database of pingbacks and regenerates its page adding whatever he wants from B
trackback
client side
A parsed
finds a link to B
downloads B
searches for RDF assertion
<rdf:Description
rdf:about="B"
dc:identifer="B"
dc:title="B Title"
trackback:ping="B tackback server/B Trackback ID" />
A does a trackback ping to B trackback server using http post
POST "B tackback server/B Trackback ID"
Content-Type: application/x-www-form-urlencoded
title=B title&url=B&excerpt=My+Excerpt&blog_name=B_Name
server side
Here the server is decoupled from B: B tackback server receives trackback posts and redelivers them to B when B pulls them
When B wants to check its trackback pings it does a
GET "B tackback server/B Trackback ID"?__mode=rss
and receives a RSS files with the list of trackback entries
Trackback is specified by the creators of Moveable Types and implemented in MT, but the spec gives you a perl standalone trackback server to use for other systems, and a perl trackback client for testing.
Trackback is a more REST-like design thanks to Paul Prescod and others.
I like the fact that they use RDF to describe the relationship between the post and the trackback url: the more metadata the better, and this is a good example of using semweb's technologies for what they're useful, ie describe relationship between resources.
I also like the fact that the trackback server is nicely decoupled from the 2 clients. This is a very symetric design and symetry is good.
Then using RSS to get the trackbacks is a nice idea, because it provides opportunity to use this results in other RSS enabled tools, such as RSS readers, in a UNIX pipes way: I expect REST-like web services .
Also B does not need to fetch A: all the needed content is in the RSS feed from the trackback server. Additional bonus, B gets all resources that link to it in one shot in the RSS file.
In Pingback, if the weblog publishing system is not hosted (such as Radio), the way that pingbacks are retrieved from the server is not specified.
So just looking at the spec I prefer trackback much better.
After writing all this I discovered that Sam Ruby has an excellent post on this topic Trackback vs Pingback where he lists other advantages of trackback.
Now to implement it in radio what do I need:
- install the perl based trackback server at my hosting provider
- create a macro in Radio to generate trackback ids for each post (there must be something like that already, a unique id of some sort, or I'll need to create a counter in a custom table)
- modify my template for homepage and archive to add trackback urls for each post
- create the ping client: this is the hardest part. i'm not very proficient in UserTalk and I'll need to beef up there. The infrastructure to do this is already there in Simon's pingback client: parse your post, get the the urls, fetch them. here it gets different: instead of looking at X--link header or link element, you need to find the RDF fragment to get the trackback url. Then the posting is also a little different: instead of using xmlrpc you use simple http post. I hope Simon's going to do it. else it'll be a good Usertalk exercise for me.
- create a template for the trackback RSS. Use a simple macro in the template to get the RSS for each post.
- modify the archive and home templates to include the trackback posts after the posts.
That sounds like fun work. I hope Simon will do it, else I'll be obliged to learn more Usertalk :-)
6:43:49 PM 
|
