[blogite] PingBack description files

Date view Thread view Subject view Author view Attachment view

From: Simon Willison (simon@incutio.com)
Date: Sat Sep 07 2002 - 17:35:27 BST


Here are some thoughts on a PingBack description file format, should we
decide to point the <link> element (and other auto-discovery methods such
as HTTP headers, XML declarations etc) to a file rather than an XML-RPC
server. I've been thinking about it and I know prefer the
pointing-to-a-file approach for the following reasons:

1. You can have one file for a whole site and point to it from multiple
pages. This is great - you can edit the one file to update your pingback
information (a huge bonus for static sites which can't easily have all
their pages updated).
2. It's a more logical use of the <link> element - browsers can view XML
files, they can't view XML-RPC servers
3. It opens PingBack up to alternative methods of sending pings (other than
XML-RPC)
4. The file can be cached if necessary by the client

Jim posted a sample XML file in an earlier message - here's my suggestion
for a format:

<pingback>
   <interface type="xmlrpc">
     http://www.bath.ac.uk/~cs1spw/blog/pingback/server.php
     <alternatives>
       <interface type="GET">
       http://www.bath.ac.uk/~cs1spw/blog/pingback/GET.php
       </interface>
     </alternatives>
   </interface>
   <interface type="email">
     simon@incutio.com
   </interface>
</pingback>

The file consists of a <pingback> element containing multiple <interface>
elements, and <interface> elements can include other interface elements
inside an <alternatives> block. The above file translates as:

"If you link to this page, please send a pingback to the XML-RPC server
located at <the url>. Please also send an email to simon@incutio.com. If
you are unable to make XML-RPC pings, please use the query string GET
interface located at <the other URL>"

As you can see, the file can ask for linkers to use multiple interfaces
(send me an xml-rpc thingy AND email me), and can also specify alternative
interfaces for clients that are unable to satisfy certain requests.

What do people think of the nesting idea? Is it too complicated? Does it
have a horrible fault that I haven't spotted?

One potential problem with the above is that interface details are
contained as a single block of CDATA. This is pretty inflexible - for
example, it would be better if PingBack servers were indicated with a host,
path and port and it would be good if email addresses could request a
specific subject. Any ideas for a way of adding that to the above format
without bloating it with too many elements (it would be good if it was
extendable as well, so the format could be used to specify a new format
like instant messenging via jabber without needing any extra elements or
attributes added to the DTD).

Cheers,

Simon

-- 
Web Developer, www.incutio.com
Weblog: http://www.bath.ac.uk/~cs1spw/blog/
Message sent over the Blogite mailing list.
Archives:     http://www.aquarionics.com/misc/archives/blogite/
Instructions: http://www.aquarionics.com/misc/blogite/

Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.5 : Sat Sep 07 2002 - 19:05:01 BST