From: Simon Willison (simon@incutio.com)
Date: Sun Sep 08 2002 - 11:53:10 BST
At 10:30 08/09/2002 +0000, Ian Hickson wrote:
>More importantly, is anyone ever actually going to use these error codes?
>There's no point adding stuff to the spec if no-one has any need for it.
>Personally I have no need for error codes. If a pingback fails I silently
>ignore it (except for logging the entire transaction), so my code never
>uses the fault error codes.
Even though they don't exist yet, I'm (sort of) using them already. For
example, if I send a pingback and get a message that says something along
the lines of "the URL specified was not a permalink on this blog" I will
try again with what I think is the correct permalink. Likewise, if the
error message says "the source page did not contain a link to the target" I
will double check that detail. I see no harm in standardising these error
conditions as error codes - that's what XML-RPC error codes are for, after all.
> > 2. The X-PingBack HTTP header alternative method of auto discovery.
> > The advantage this it allows non-HTML resources on the web to be
> > PingBack enabled [...].
>
>The disadvantages are extra overhead (everyone has to implement
>X-Pingback, otherwise what's the point), and redundancy (if everyone
>implements one, why need the other).
I don't see why everyone would need to implement X-Pingback. It should be
an optional part of the spec - if your client implementation wants to be
able to handle PingBacks to non-[X]HTML content it should implement the
ability to read the header, if not then it can forget it exists and rely on
the <link> auto-discovery method.
>Why do we want two different pingback mechanisms?
>
>Do we ever really want to pingback to a non-(X)HTML document? The spec
>current says that only (X)HTML documents may be pinged-back.
I think we do. Case in point - your "Sending XHTML as text/html Considered
Harmful" document is text/plain. I'll be linking to it later on today (I'm
trying to think of excuses to stay with XHTMl at the moment, not doing too
well so far :P ) - if the PingBack spec allowed for X-PingBack headers you
would be able to receieve a ping when I did so. There's plenty of
interesting content out there that people may want to link to that does not
come in an [X]HTML document - multi media files, XML documents (bloggers
link to RSS feeds and OPML files all the fime). The X-PingBack header can
enable PingBack for these as well.
> > What do people think of the XML processing instruction auto-detection
> > method (also mentioned in the above email) ?
>
>I think we definitely should not do this. :-) IMHO we should either stick
>with <link>, or switch to X-Pingback. I don't see any need for a third
>mechanism, since the other two already cover everything the PI can do.
Agreed - I'm still very strongly in favour of the additional X-PingBack
method (in addition to the <link> element because many people are unable to
modify HTTP headers) but if we go with it the XML processing instruction is
unnecessary.
Final thought - should we go with X-PingBack it should over-ride any <link>
element in the document. This is for two reasons: Firstly, doing so allows
people with static sites to over-ride the PingBack tags on their older
content with a .htaccess style directive, and secondly the current
suggested implementation for X-PingBack is that clients stop downloading
the document as soon as they find one of those headers, meaning they would
not see the <link> element anyway.
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/
This archive was generated by hypermail 2.1.5 : Sun Sep 08 2002 - 17:05:00 BST