0xDECAFBAD

It's all spinning wheels and self-doubt until the first pot of coffee.

Pingback may one-up TrackBack

I've got some further thoughts on Pingback, provided that my server humors me.



David Watson says, "uh, no," citing a horrible experience in actually trying to see the spec in the first place, and a lack of working code. Not to mention that my site was having a seizure last night - not good things to recommend that one check out a new technology.



Well, I did manage to see the spec, but haven't tried implementing it yet. (Though it shouldn't be too hard, given a few round tuits.) A few things, in particular that I like about Pingback:

  • URIs are used to specify the source and target of the ping, no other information is involved in setting up the relation (ie. arbitrary IDs, etc). This makes site-wide integration of Pingback drop-dead simple - everything's already identifiable via URI.
  • If one implements Pingback HTTP headers, one can allow non-HTML resources to be pinged. (ie. Ping my FOAF file when you add me to yours, and I might add you to mine. That might be pushing the spec a bit, though.)
  • The XML-RPC server is not tied to any sites it may serve. I could offer one here, and you could point to it from your site, and if I allowed it I could record pings for you as a service.

All-in-all, Pingback just seems like a more direct, intentional form of referrer log.



One thing I don't like about Pingback, though (and the same for referrer logs): It's just about URIs and links between them. It says nothing much about titles or excerpts or comment bodies. The spec suggests that a Pingback server might retrieve "other data required from the content of Alice's new post," but makes no statement on how this is to happen. I like that TrackBack sets down how to provide a bit more information.



I've got a vague idea in my little head, and I think it's something Sam Ruby touched on: ShowReferers, form-submitted comments, TrackBack, and Pingback are all just different on-ramps to inviting open participation in discussion on one's blog. I want to take a shot at implementing Pingback very soon - but I might also try taking a shot at implementing a unified comment system that accepts comments for any URI from any of the aforementioned sources. I'd also like something that scans a blog entry I post for links, then investigate those links for Pingback/TrackBack availability - all to make the system even more automatic. I doubt that it would be very difficult, though I am notoriously naive. On the other hand, I've been on a run of making hard things simple lately. :)



But I sense my round tuits slipping away - back to work!

shortname=ooobib

Archived Comments

  • Ian Hickson
    "something that scans a blog entry I post for links, then investigate those links for Pingback/TrackBack availability" is exactly how most pingback clients work at the moment.
  • mort
    " The spec suggests that a Pingback server might retrieve "other data required from the content of Alice's new post," but makes no statement on how this is to happen." Well, as the server scans the referrer for checking the authenticity of the ping, etc.. it can grab pretty much what it wants: lang attributes, page title, excerpts...
  • l.m.orchard
    it can grab pretty much what it wants: lang attributes, page title, excerpts... How and where does the server scan the referrer for things? I'd like that specced and defined. The answer now is "anyway you want to do it". Yuck. Regexes and matching and scraping, oh my. Been there, done that. :) I'd like some agreement on what my server should expect to find on the other end of an incoming Pingback ping. Maybe some embedded RDF in the page, or some metatags in the header. Something that says, "Title is [here], author is [here], exerpt is [here], language is [here]..." I don't want to do much work or digging or regexing or scraping or whatever from incoming ping to incoming ping. Let's just agree on where to look for it. Of course, this whole wish falls apart if the incoming ping is not XML or HTML.
  • Ian Hickson
    Assuming it's HTML or XHTML: The title is in the <title> element. The auther is in the <meta name="author"> element The content is everything in <body> unless there's a fragment identifier, in which case it's everything in the element that the fragment identifies. The language is the value of the lang attribute on the <body> or other element matched in the previous step, after handling the language inheritance rules. This is all very well defined in the HTML specs. You can get more metadata out using Dublin Core metadata stored in <meta> tags. Why should the pingback spec attempt to redefine all this again, given that the information already exists?
  • Ian Hickson
    er, your blog killed my comment! Bug! (The text word was angle-bracket-title-angle-bracket, for what it's worth.)
  • l.m.orchard
    Ugh, yeah, have to look into that HTML cleaning plugin a bit more. It should escape things like a title tag while allowing a bold tag. Ian: No need to redefine all the above - just specify it. State that in the spec, strongly suggest it or require some subset of DC in meta tags. I want to know that, when I send a ping at a supporting (X)HTML page, I can expect to find some metadata in an agreed upon way. If that's DC in meta tags, great. Just a matter of saying "this is what's done" rather than "you kinda could do this".
  • Ian Hickson
    I don't think it's the place of the pingback spec to specify what metadata a document should contain. It would be like the URI or XLink specs requiring documents to contain metadata, or the PNG spec to require that images not contain red flowers -- it's not their place to worry about it. If the pingback spec required DC metadata, then it would just be adding one more dependency, one more spec that we'd have to monitor in case it affected pingback in some way. When you ping a page, you can expect to find all the metadata that the HTML spec says you can expect to find. If you want documents to have more, speak to the HTML working group. :-)
  • l.m.orchard
    Yup - right you are. The HTML spec is where metadata declaration belongs, and the DC-in-HTML spec I found today is the suggestion I was looking for. I was just looking for love in all the wrong places, but the simplicity in Pingback is nice.