- From: Michael Burrows <asplake@freenetname.co.uk>
- Date: Fri, 3 Jul 2009 16:01:06 +0100
- To: Mark Nottingham <mnot@yahoo-inc.com>
- Cc: Phil Archer <phil@philarcher.org>, ietf-http-wg@w3.org
2009/7/3 Mark Nottingham <mnot@yahoo-inc.com>: > The cookie strategy (or anything like it) isn't good for caching or scaling. That concerns me too. I may have to accept that most clients won't be interested in links, and let them specify explicitly (perhaps by a query parameter) which ones they need. > > I think -- as in many things -- this requires a judgement call by the > author. If you're slinging around hundreds of links on every response, > there's a good chance that you're doing something wrong; odds are that most > of the links will be irrelevant to most use cases. Refactoring into separate > representations, etc. makes sense here. I would agree. Certainly not hundreds of links ; generally just a handful, perhaps a few more on top level landing sites. Anyone wanting the template for the whole site can get that separately. > > In this way, it's no different to deciding what is at the other end of a > URL; too fine-grained, and it's not useful, but too coarse-grained and > you're giving too much information and overloading the infrastructure. Of > course, what the infrastructure can take changes over time too. > > Cheers, Regards, Mike > > On 23/06/2009, at 7:11 PM, Phil Archer wrote: > >> 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 >> > > -- > Mark Nottingham mnot@yahoo-inc.com > > > >
Received on Friday, 3 July 2009 15:01:47 UTC