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

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:01:22 UTC