From: Jim Dabell (jim-blogite@jimdabell.com)
Date: Sat Sep 07 2002 - 17:38:04 BST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 06 September 2002 6:45 pm, Simon Willison wrote:
> At 17:48 06/09/2002 +0000, Jim Dabell wrote:
[snip]
> >There is no reason to not support both - if you can't implement the http
> >header method for some reason, you can include it in a <link> element -
> > if a pingback implementation doesn't find the http header, it can
> > always try the other method.
>
> My biggest objection to the HTTP header method is this: A very, very
> large proportion of the sites linked to will not have PingBack of any
> kind. This means that for most sites you are linking to you will have to
> perform a HEAD request, see that they don't have a PingBack header, then
> perform a second GET request and see that they don't have a <link>
> element either. That's two requests, which is actually a greater overhead
> than just sending a GET!
Surely the overhead for HEAD in this context is negligable?
> Also remember that you can read data from a socket line by line (or
> character by character if needs be). This means that you can close the
> socket connection from the GET request the moment you receieve a <link
> rel="pingback" element OR you hit the </head> tag (as the link element
> will not appear past that point). This means the overhead isn't actually
> that bad.
Think about all the screwed up html without </head> or <body>, coupled with
thousands of keywords etc. Sure, you can drop the connection after 32k or
whatever, but that's a big difference to a few lines of HTTP headers. You
could also require that the <link> is the first element of <head>, but I
think adding parsing requirements on top of standard html is a mistake.
> >- - pingback checks to make sure the permalink url is actually in the
> > page
> >
> >It seems to me that this should be an optional part of the spec anyway -
> >some implementations won't want the overhead.
>
> While I agree with Stuart that it is a very, very good idea for a
> PingBack implementation to check for a link on the page I agree with you
> that this should be optional. I think the PingBack specification should
> pretty much boil down to what amounts to a single line of text:
>
> Blog A tells blog B: "I have linked to your page X from my page Y"
Agreed.
> This doesn't even have to be done via XML-RPC (although that should be
> the favoured method).
The "correct" approach imho would seem to be <link>ing (or HEADing) to a
description of the available pingback interfaces instead of directly to the
service. You could list several:
<pingback>
<interface priority="1" type="xml-rpc">
http://www.example.com/xml-rpc-address
</interface>
<interface priority="1" type="http-get">
http://www.example.com/submit.php?linker=
</interface>
<interface priority="2" type="email">
pingback@example.com
</interface>
<interface priority="10" type="manual-web-form">
http://www.example.com/feedback/
</interface>
<interface priority="10" type="manual-email">
feedback@example.com
</interface>
</pingback>
[snip]
> Getting back to the overhead problem, I have a working prototype of a
> centralised system that could severely reduce overhead by helping blogs
> maintain an internal list of which URLs are PingBack-able (and which
> server they should ping).
I *much* prefer autodiscovery. A client could (optionally) keep a cache of
the last few sites linked to, to avoid overhead of checking the same site
ten times a day, but that should _really_ be implementation-specific.
[snip]
> Oh, and welcome to the list :)
Ta :)
- --
Jim Dabell
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9eits3tJNldoQhi8RAu5DAJ9iWMAVX7VyyrqhknJbjij+TQDRpwCfROGE
VOvEzVvAtXpDBKKBflnohKI=
=Yb69
-----END PGP SIGNATURE-----
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 : Sat Sep 07 2002 - 19:05:01 BST