From: Jim Dabell (email@example.com)
Date: Sat Sep 07 2002 - 18:59:33 BST
-----BEGIN PGP SIGNED MESSAGE-----
On Saturday 07 September 2002 4:35 pm, Simon Willison wrote:
> <interface type="xmlrpc">
> <interface type="GET">
> <interface type="email">
> 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 firstname.lastname@example.org. 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
> What do people think of the nesting idea? Is it too complicated? Does it
> have a horrible fault that I haven't spotted?
I prefer mine, sorry :). The "priority" that I used in my suggestion was
inspired by dns/mx priorities - start with the lowest number (if two
methods are equal, decide by yourself), and if one fails (or you can't
implement it for any reason), move on to the next method, until you find
one that works. I'm not sure if that was clear or not, or if you just
don't think it's useful.
The notion of having multiple notifications is a good one, but I feel that
ultimately, the mechanism put into place by the server should deal with
this - apart from anything else, it's more reliable.
> One potential problem with the above is that interface details are
> contained as a single block of CDATA.
I'm not quite sure what you mean - you mean the URL etc are free-form,
instead of as an attribute? I agree, I don't particularly like it, but I
thought that was just because I am used to html hrefs.
Part of the reasoning behind putting it in that way was because an attribute
should have a certain type, and stick to it. The same applies to an
element of course, but in this case, they are different types of element.
I see two alternatives:
1. Different attributes for different interfaces. This is messy, and
confusing, I think.
2. Go the w3c route, and make them all URIs. Instead of a simple email
address, you'd have href="mailto:email@example.com". I don't know what's
available - is there an xml-rpc:// URI scheme? How extendable would this
be? We don't want people just making up URI schemes left, right & centre.
One thing I didn't particularly like about the http-get interface was that
you either have to assume a certain query string, or build it into the xml
file somewhere. On the one hand, relying on certain semantics that aren't
captured by the xml file is messy and not easily extendable, but on the
other, I can't see a real way of doing it elegantly in the xml file.
> 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.
Good idea. The URI method solves this.
> Any ideas for a way of adding that to the above
> format without bloating it with too many elements
To a certain extent, I'm not really concerned about bloat, as long as it
ends up being useful and does the job well.
> (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).
That should be a priority, imho.
The only thing I would say is really important is to add a version attribute
to the root element - if this is likely to be a format that changes quite a
bit initially, there really shouldn't be any need to build complex
heuristics just to figure out which version it is.
One of the things I was considering adding to the feature list of my almost
completely unimplemented blog feature set is notification via IM of things
like replies to comments you've posted, or replies to articles. Kind of
like "watch this thread". It occurs to me that there may be some overlap
here (as this is basically just a description of notification methods), but
I definitely don't want to think about that too much at the moment.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----
Message sent over the Blogite mailing list.
This archive was generated by hypermail 2.1.5 : Sat Sep 07 2002 - 21:05:00 BST