Re: [blogite] PingBack description files

Date view Thread view Subject view Author view Attachment view

From: Aquarion (
Date: Sat Sep 07 2002 - 20:32:08 BST

On Sat, Sep 07, 2002 at 05:59:33PM +0000, Jim Dabell wrote:
> Hash: SHA1
> On Saturday 07 September 2002 4:35 pm, Simon Willison wrote:
> [snip]
> > <pingback>
> > <interface type="xmlrpc">
> >
> > <alternatives>
> > <interface type="GET">
> >
> > </interface>
> > </alternatives>
> > </interface>
> > <interface type="email">
> >
> > </interface>
> > </pingback>

This is the last time I'm going to post about this, because if you don't
get that I don't think this is a good idea by now, I've got no hope, and
might as well give up anyway.

The interface you've just described is to tell a given client how to
ping back to my blog. In order to do this, the client side has to
impliment four *differant* methods of how to ping people. This is four
times more work than needs to be done. The way it *should* be done is to
pick one standard and stick with it (What's the point of a GET
mechanism? Every language capable of being a blog server is also capable
of processing text in some form, and thus XML. Most languages (excluding
things like COBAL and Intercal) have some sort of XML translator.) at
that point the *SERVER* can work out whether to put it in a database,
put it into a file, or just email the data to the webmaster. This should
not be a client side thing at *all*, all the client should have to so is
send off a single defined packet that says "I linked to you" to a URL
that it finds. How it finds that URL is arguable (I'd say the <link> tag
is the best bet, personally) but forcing ALICE to jump though hoops just
to /mention/ BOB's blog is fast entering the mysical realms of taking
the piss, esspecially when all you are doing is asking for the
information in four differant ways. Data processing is a server task,
not a client one. Besides which, we are entering request time problems
here. In a single pingback, I now have to get the host name, query it
for the file, parse the file (twice if we do the header thing), look up,
download and parse
another file, compose a file to send, connect to the server we got from
the second parse, and send the file. And that's only if we don't support
email. Which is a second point, you are relying on all given clients to
support the way the *webmaster* wants the information delivered. Not all
webservers have access to an smtp server (Nor should they have to be),
This system requires the *client* to know about all the possible ways
the *server* can want to read information. Where does this stop? Do we
spend the next year finding all possible data transfer methods and
defining a pingback standard for all of them (FTP? SOAP? TFTP? IRC
Query? Something that connects to your Quake server and tells you about
it?). The clients job is to send and recieve data, processing it for how
the server wants it is a server job.

I'm starting to repeat myself, so I'll stop.

Message sent over the Blogite mailing list.

Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.5 : Sat Sep 07 2002 - 22:05:00 BST