- From: Michael Burrows <asplake@freenetname.co.uk>
- Date: Thu, 25 Jun 2009 15:18:28 +0100
- To: Phil Archer <phil@philarcher.org>
- Cc: ietf-http-wg@w3.org
- Message-ID: <7a2269960906250718k37d2ea41h733428dcff90004c@mail.gmail.com>
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 > >
Received on Thursday, 25 June 2009 14:19:03 UTC