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

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 13:28:41 UTC