From: Jim Dabell (jim-blogite@jimdabell.com)
Date: Sat Sep 07 2002 - 18:03:48 BST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 06 September 2002 6:17 pm, Stuart Langridge wrote:
> Jim Dabell spoo'd forth:
> > Hi, hope this is a public mailing list, and it's okay to post and not
> > just lurk - I came across this list by accident, so I'm not sure :)
>
> No worries, get stuck in ;)
Ta :)
[snip]
> A lot of blogs *are* static, though, because they build static pages
> for rendering speed, even if you do have CGI access to the headers. If
> I were using static pages I certainly wouldn't want to do the overhead
> of kaing all my pages a CGI.
Use .htaccess or the fallback then :)
Also: how many static blogs are likely to be running a pingback server?
> > - - head is not well supported
> >
> > This is the first I've heard about this. What servers don't support
> > head?
>
> I must confess that I'm taking someone else's word for this. However,
> the someone is Jamie Zawinski, who I expect to know about this stuff.
> From http://www.jwz.org/hacks/marginal.html: "...then does a GET on
> each of them (not a HEAD, because that doesn't work with all sites)..."
Fallback when you recieve "501 Not implemented" then, and drop the
connection even earlier if you get a pingback http header from your GET :)
> > - - 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.
>
> I don't agree here. Checking for a reference prevents pingbacks being
> spammed or flooded. I've seen too many examples of protocols where
> people think of this sort of thing later on and find that it's a real
> pain to retrofit; if we make it part of the spec up front then we'll
> never have to worry about it.
Perhaps a recommendation, rather than actually part of the spec? For
instance, in HTML, there is no defined error handling, but there is a
"recommended" approach that virtually all implementations implement.
> > Which (in a roundabout way) leads me to my next question:
> >
> > What are the semantics for changing pages? Suppose you get a pingback,
> > and the referring page deletes the reference to you? Or the site goes
> > offline, never to come back?
>
> Ah, but Cool URIs Don't Change, remember?
> http://www.w3.org/Provider/Style/URI.html
Ah, but this is the _real_ world, remember? ;)
> I'm not necessarily seeing a need to cope with this; after all, links
> that have been blogged may go dead or move and no-one worries about
> that particularly, I don't think?
Good point..
[snip]
> 1. You should be able to tell a page's pingback URL from the page in
> isolation, because it relates to the page. HTTP headers aren't the page
> at all, they're merely the method by which the page is served, which
> should be irrelevant to what you do with its content. It would be
> possible to serve a site from an ftp server (if you were a nutter) and
> you might still request pingbacks, but there would be no headers -- how
> a page is given to the user is irrelevant. It's the content that's
> important.
Fallback :)
Seriously, though, I see pingback servers as being a property of the blog as
a whole, rather than any specific page. I guess you don't, which is why we
disagree on this point.
> 2. Headers are invisible and weird techie things. It'll be jolly
> difficult to explain them to people (although, I admit, my plan for
> pingback is that it happens automatically without user intervention).
Good point, however if they are using a pre-packaged dynamic blog, then this
can be handled automatically too.
> 3. The LINK tag is, in my opinion, the Right Way to show stuff related
> to a page, like alternative representations or CSS that relates to it.
> That's what it's designed for, and that's how it should be used, I
> think; it's clearly the way to show the pingback server related to a
> page.
I think there's a case to be made for both approaches. Certainly, HTTP
headers are the _definitive_ way to provide meta information about objects
retrieved via HTTP. Content-type, caching, content-language - all are
present in both <head> and http, there is *some* overlap.
The test I would see as being whether or not it should be in the document or
the headers is: does pingback make sense outside of html? If a new
document type took the world by storm, would it still make sense to have
pingback operating on those documents?
I hope I've made it clear that I'm not actively opposing <link>, just
advocating a HTTP header as the authorative information. As noted above,
there is some overlap between HTTP headers and <head> elements, this is
probably one of those cases where both methods should be implemented.
Also, what about xhtml (the proper stuff, not text/html)? Are we going to
have <?xml-pingback ... ?> as well?
- --
Jim Dabell
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9ejF03tJNldoQhi8RAsbYAJ9D7Ob7GzqhP1A1SpdQzZaJMHRaAACffZA0
QyOLjrKX9pf2SqXCI3ebj2g=
=lX34
-----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 : Mon Sep 09 2002 - 04:05:01 BST