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

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
>
>