TrackBacks are Comments are TrackBacks.

I've been under the weather and struggling to remain focused and coherent. The great discussions on the topic of TrackBack and open interfaces carries on.

Ben Hammersley summarizes the various x-Backs being discussed here with a late omission here.

Rael Dornfest put out a call for a discussion script suggestions that I answered. The forthcoming Blosxom 0+7i features a plugin architecture that Rael is currently testing on his site. Rael writes:

A suggestion by Tim Appnel on the Blosxom mailing list tickled a thought I'd had before but promptly forgotten about: Why not use the MovableType standalone TrackBack implementation as a comments system?

Only a couple-three minor tweaks later, a copy-n-paste from my Blosxom trackbacks module, and I have Comments a la Trackbacks! Give 'em a whirl by clicking the "comments" link associated with this (and every) post.

He's testing it on his weblog now. I'm glad Rael liked my suggestion. In essence there is little difference between the two. Sam Ruby agrees. My hope is that these discussions will result in this being abundantly clear and that a more refined standard interface emerges.

Rael's comments implementation based on TrackBack is still kept separate from TrackBack pings. In the comment board for the entry I asked Rael Why differentiate between comments and trackbacks? You're using the same infrastructure, why must the display be different? Combining the two and taking the approach you have you now have a remote commenting API by default. This opens up a whole range of new possibilities. Rael explains that comments was a less then 1 hour hack of the standalone TrackBack application that he didn't want to impact his existing TrackBack database. This is understandable.

Sam Ruby is experimenting with PingBack and has implemented excerpts via RSS discovery. With PingBak becoming more like TrackBack and vice versa, Ben Hammersley points to some writings on PingBack merits in comparison TrackBack. I read these papers when they where released and reacquainted myself with them again. The papers do point out some shortcomings of TrackBack 1.0 and 1.1 that I agree with.

• The specification is too loose and is mixed in with the MT implementation. It took quite a bit of effort by myself to boil it down to what I believe is the essence of the standard. I believe my XML:TrackBack module represents its current state in code.
• Discovery could be made easier and more elegant by storing TrackBack info in a separate file and pointing to is with a <link> tag. (And yes the regular expressions in both MT and the reference implementation are not sufficient bordering on flawed.) Perhaps an optional RESTful lookup service is warranted. the commenting out of ping info is a bit of hack. While I believe in standards compliance, personally I'm not terrible appalled by this. It is easy to implement, requires no additional software and it works reasonably well. Should we improve on it? Absolutely. In due time.
• It would be more RESTful to use HTTP message rather then make up their own. The status messages the TrackBack implementations generate are not terribly helpful to a developer anyway.
• TrackBack does not support arbitrary formats such as images, PDFs and so on. Given the scope and the life TrackBack is taking on, I'm not sure what value supporting arbitrary formats would provide. Something could be implemented with a little modification to the TrackBack core such as alternate ways of auto-discovery.
• While multiple pings in one page can be ambiguous. While permissible it is not a advisable or neighborly practice. More needs to be done to clarify this.

I'm not in complete agreement though as some criticisms are flawed.

• TrackBack does not require an entry to have a different permalink and TrackBack ID. The implementation of TrackBack in MT works that way because of its feature set, but it is not required. A TrackBack ID can be anything including a URI. In other words /cgi/tb.cgi/archive/entry.html is a valid TrackBack ID assuming the implementation of tb.cgi understand how to resolve the path info (/archive/entry.html) to register the ping.
• PingBack is not necessarily easier to install particularly if you don't have an XML-RPC server or access to your servers .htaccess logs. This easecould be implemented with the afore mentioned optional RESTful lookup service. (I would assert that it would be even easier because the need for XML-RPC infrastructure is not necessary -- I admit to having RESTful leanings though.)
• The RDF used by TrackBack is an XML serialization of XML. Any XML parser should be able to parse it once extracted from the HTML. That said it be done better perhaps with RSS instead of purely RDF.

After contemplating these papers, I'm still struggling to see what value PingBack really buys me particularly if TrackBack is refined as I believe it will . PingBack's scope seems far to limited even with Sam's experimental functionality.

What I find puzzling is that the developers of PingBack did not try (to my knowledge at least) and work to improve the TrackBack specification as Paul Prescod and others have. Furthermore, the tone in Ian Hickson's papers seems a bit harsh. (Why?)

What ever the case, this is all very good progress that I believe is leading to a better understanding and cohesion. I'm brimming with enthusiasm for where this is all leading.