W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: draft-nottingham-http-link-header-05: a question and an experimental implementation

From: Michael Burrows <asplake@freenetname.co.uk>
Date: Thu, 25 Jun 2009 15:18:28 +0100
Message-ID: <7a2269960906250718k37d2ea41h733428dcff90004c@mail.gmail.com>
To: Phil Archer <phil@philarcher.org>
Cc: ietf-http-wg@w3.org
Thanks, I'll do that.  I was in contact with Eran some time back (before I
had anything very concrete) in the hope that everything I'm doing was done
already.  It does still seem that I'm breaking some new ground, though
there's back-tracking to be done every time it transpires that I've
overlooked some previous work.  That's the price of trying to do the right
thing I guess!

2009/6/25 Phil Archer <phil@philarcher.org>

> Hi Mike,
> That makes sense and, as I guess you know well, there's a module on 'role'
> for XHTML [1].
> With all those links, perhaps with additional type="MIME-type" attributes,
> I quite see why you're concerned about shipping so many bytes with every
> request.
> You might want to take a look at Mark Nottingham and Eran Hammer-Lahav's
> work in site-meta and discovery at [2] and [3]. These are beginning to look
> a little out of date now but AIUI you'll be able to put all your links in
> the well known location to end all well known locations (actually, I think
> they're now gunning for /well-known) and then put all your links in a text
> file at that location.
> Phil.
> [1] http://www.w3.org/TR/xhtml-role/
> [2] http://www.mnot.net/drafts/draft-nottingham-site-meta-01.txt
> [2] http://www.ietf.org/internet-drafts/draft-hammer-discovery-03.txt
> Michael Burrows wrote:
>> Thanks Phil, that seems reasonable enough.
>> For the record (expanded somewhat in [1]), I went with "role" to fix
>> my erroneous use of "type" and its values are URIs now.  Very much
>> along the lines of Tim BL's Metadata Architecture note [2] it
>> generates globally unique identifiers not only for relationships but
>> also their source and target entities in a logical ER view of the
>> application, the entities corresponding to the application's templated
>> "routes".  Moreover those identifiers point ("hash fragment" style)
>> inside metadata documents.
>>    [1] http://positiveincline.com/?p=392
>>    [2] http://www.w3.org/DesignIssues/Metadata.html
>> Regards,
>> Mike
>> 2009/6/23 Phil Archer <phil@philarcher.org>:
>>> Hi Michael,
>>> Michael Burrows wrote:
>>>> Re my last paragraph below, I hadn't checked RFC 4287 for a
>>>> description of the "type" attribute.  Newbie error, apologies.
>>>> With that out of the way, what's the thinking on the duplication of
>>>> link elements and link headers?  Are there mechanisms for UAs to
>>>> indicate which they prefer?  I've been through a year's worth of
>>>> archive now and didn't find this addressed anywhere.
>>> I'm not aware of any such mechanisms but it's a point that I've heard
>>> raised
>>> informally. Adding in a bunch of links in the HTTP response to every
>>> request
>>> when they're not required is the kind of thing that gets server
>>> infrastructure engineers very upset.
>>> However, I don't think there's a need to invent anything new here.
>>> Cookies
>>> could easily be set that indicated that Links had already been consumed
>>> by a
>>> given browser. Of course, that only applies on the second and subsequent
>>> requests, not the first one, so it doesn't answer all your point, but it
>>> gets pretty close?
>>> Opera and FF both implement HTTP Link (see [1] for example) but Chrome,
>>> Safari and IE don't. It's pretty easy therefore to configure a server to
>>> include HTTP Link for those browsers based simply on the UA string and
>>> put
>>> in the HTML link elements for the others? Again, not a complete solution,
>>> I
>>> know, but a practical way forward?
>>> Cheers
>>> Phil.
>>> [1] http://www.fosi.org/archive/httplinktest/
>>>  2009/6/19 Michael Burrows <asplake@googlemail.com>:
>>>>> I have a question on draft-nottingham-http-link-header-05: is there an
>>>>> agreed mechanism for clients to indicate whether they want link
>>>>> headers, the equivalent html/xml elements, or neither?  It seems
>>>>> wasteful to generate redundant or unneeded data, especially while
>>>>> client support for the headers is not widespread.   Apologies if this
>>>>> has been covered previously (I did review the April-June archive).
>>>>> Meanwhile, you may be interested in an experimental implementation of
>>>>> link headers (&/or elements) for Ruby on Rails, generating them from
>>>>> metadata constructed from the application's routing config.  Please
>>>>> drop me a line if you'd like to play with it.  There is a Python
>>>>> library too but it lacks the server framework integration.
>>>>> I went with the hash URI approach [1] to identifying extension
>>>>> relation types, with the fragment pointing inside the metadata
>>>>> obtainable (in multiple formats) via the "describedby" links.  See for
>>>>> example the last two links below:
>>>>>  Link: <http://example.com/users/dojo>; rel="self"; type="user",
>>>>>        <http://example.com/described_routes/user>;
>>>>> rel="describedby"; type="ResourceTemplate",
>>>>>        <http://example.com/described_routes/user?user_id=dojo>;
>>>>> rel="describedby"; type="ResourceTemplate",
>>>>>        <http://example.com/users>; rel="up"; type="users",
>>>>>        <http://example.com/users/dojo/edit>; rel="edit";
>>>>> rel="http://example.com/described_routes/user#edit"; type="edit_user",
>>>>>        <http://example.com/users/dojo/articles>;
>>>>> rel="http://example.com/described_routes/user#articles";
>>>>> type="user_articles"
>>>>> If I interpret the spec correctly, there is no strong guidance on the
>>>>> use of the "type" attribute.  I hope that my usage here seems
>>>>> reasonable.
>>>>>  [1] http://www.w3.org/TR/cooluris/#hashuri
>>>>> Regards,
>>>>> Mike
>>>>> mjb@asplake.co.uk
>>>>> http://positiveincline.com
>>>>> http://twitter.com/asplake
> --
> Phil Archer
> http://philarcher.org/
> i-sieve technologies                |      W3C Mobile Web Initiative
> Beyond Impressions                  |      www.w3.org/Mobile
Received on Thursday, 25 June 2009 14:19:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:40 UTC