- From: Phil Archer <phil@philarcher.org>
- Date: Thu, 25 Jun 2009 15:00:36 +0100
- To: mjb@asplake.co.uk
- CC: ietf-http-wg@w3.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:01:22 UTC