TrackBack, Moving Forward

Timothy Appnel has summarized and expanded upon the many ideas and suggestions for the next generation of TrackBack. He's also providing a repository for other comments on the issue.

Here are my thoughts on some of the issues raised in the proposal.

Paul Prescod suggested to us, around the time that we released version 1.1 of TrackBack, that we switch to using RSS to represent the ping data (excerpt, title, etc), and to a fuller REST model. This is probably #1 on the list for a 2.0/NextGeneration version of TrackBack. It's nice because it's symmetrical: to send a ping, you POST RSS; to retrieve a list of pings, you send a GET, and get back RSS.

I think the fuzziest area is the auto-discovery option. TrackBack auto-discovery is currently tricky to implement and can be bandwidth-intensive. It's true that <link> tags are one method of improving the process, but it's not always that simple. For example, on an index page of entries, it is non-trivial to determine the list of entries that will appear on the page prior to actually parsing the page, but doing so is necessary for preparing a separate file that could be used in a <link> tag.

Regarding this statement:

TrackBack Ping ID guidance. There seems to be some confusion here and could use further clarification and refinement.

I think that the confusion referred to is, "what is a TrackBack Ping ID?" And the answer is, anything you like. TrackBack has been critized, in the past, for having two different URLs and IDs for TrackBack items and entries--but this is only a consequence of the Movable Type implementation, where a TrackBack item is an abstraction over an entry or a category. A TrackBack ID can be anything at all, even a full URL: for an example, look at Rael's usage of the standalone TrackBack tool, where he uses IDs like "science_space_remember_to_look_up", generated from the entry category and title.

Another interesting idea in the proposal is this:

Specify the discovery and function of an optional TrackBack information service. The main purpose of this service is to make auto-discovery more efficient and scalable then grabbing an HTML page and scraping it.

This would obviously improve auto-discovery: register a TrackBack ping URL with a service, then allow clients to ask you for the TrackBack ping URL, given a permalink. (It does detract somewhat from the decentralized structure of TrackBack, though.)

Anyway, it's great to see progress related to TrackBack, and we hope that the discussion continues.