RE: Using Content Negotiation to relate "data resources" to AJAX user interfaces

Thanks, Sebastien.

I understand the use of the fragment identifier as a workaround for
Javascript access to the browser location bar, but my basic dilemma would
still exist without this problem. My fundamental dilemma is that the user
has in hand a URL that references some "information resource" (I'm using
emails as an example even though afaik GMail doesn't expose URLs for the
emails themselves) and I need a mechnism to allow the user to get into an
appropriate AJAX client initialized on the IR.

>> Conneg should be used when two documents are the same enough that they
can be swapped around without too much limitation.

We understand that this is the stabdard advice, and that returning the code
for an email client when someone asked for a representation of an email
violates the spirit of this. Our problem is that we don't have another
solution with attractive user characteristics.

Thanks for your interest in our question and sorry if didn't fully
understand the response.

Best regards, Martin

Martin Nally, IBM Fellow
CTO, IBM Rational
tel: (949)544-4691



                                                                           
             Sebastien Lambla                                              
             <seb@serialseb.co                                             
             m>                                                         To 
             Sent by:                  Martin Nally/Raleigh/IBM@IBMUS,     
             www-tag-request@w         "www-tag@w3.org" <www-tag@w3.org>   
             3.org                                                      cc 
                                                                           
                                                                   Subject 
             02/24/2009 03:16          RE: Using Content Negotiation to    
             AM                        relate "data resources" to AJAX     
                                       user  interfaces                    
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Martin,

      The base URL for Gmail is http://mail.google.com/mail/ which appears
      to redirect to http://mail.google.com/mail/#inbox. Within your inbox,
      you can click on an email - if you do, Gmail will open your email and
      the browser address bar will change to something like this:
      http://mail.google.com/mail/#inbox/11f804dfae358bd9. An improbable
      number of POSTs and GETs go on under the covers before this URL
      appears and none of them would make you expect that this URL would
      appear, but somehow it does - GMail is not simple. Security will
      hopefully stop you from following this link to this email, but I can
      do it. So GMail provides me with URLs for each of my emails of the
      form http://mail.google.com/mail/#inbox/11f804dfae358bd9, and it
      makes those URLs appear in the address field, which is where users
      would expect they would appear.

There's two aspects here. The first one is not to be ignored, an email is
an IR, and identifying the email "the thing" and the email "the byte
stream" doesn't make much sense. The hash URI exist only because of
javascript limitations that prevent the location bar from changing when
navigation is done from within the page. I think it's important to
highlight the fact that this is not a technical choice but a workaround
current browser limitations.
      L representation, content-negotiation would again give the right
      thing. This is a huge improvement in usability of my solution.

      So why don't we just implement thisdesign? The objection, pointed out
      by several of our developers (and me) is that it's a distortion to
      say that the GMail HTML returned by
      http://mail.google.com/mail/#inbox/11f804dfae358bd9 is a
      representation of the email. It's more reasonable to think of it as a
      JavaScript program that turns around and does a bunch of further GETs
      and POSTs in whose responses are somewhere buried a representation of
      the email. I'm guessing this is why the authors of the paper cited
      above advised against using content negotiation for this case - it
      seems like a hack that is not in the spirit of the web architecture.

Conneg should be used when two documents are the same enough that they can
be swapped around without too much limitation. Enabling rfc822, xml and
json on such a "data URI" is quite a valid approach.

What I have implemented in the past is a methodology for discovery of the
real URI for a hash URI. This looks like this:.
/mail/inbox/1 is the email on which conneg can be done amongts formats with
enough sameness
/mail#inbox/1 is the hash URI for the email that is used for identifying it
in the browser (until javascript is given access to the location bar)
/mail is a resource containing the links to the email entries for clients
given the hash uri so they can redirect themselves to the correct location

mail contains links using either a standard media type or a custom format.
For example:
200 OK
Content-Type: application/vnd.acme.maillist+xml
Vary: Accept:

<mailbox>
 <link identifier="inbox/1" href="/mail/inbox/1" />
</mailbox>

The html document contains javascript code that goes and fetch the email
identified by the fragment. In REST parlance, we're talking about mobile
code to provide a user-agent that doesn't understand a media type specifics
to parse it.

And indeed, the reosurce you're accessing is *not* your email, it's
the /mail resource, for which you have a fragment URI.

Provided you define your media type to define the @identifier attribute to
be the handler of the fragment, and ideally provided that you indeed, in
the original /mail html representation, you have a <a name="xxx"> as a link
to the mail, you are approaching the sameness requirement.

The last contentious bits is, in the case of html, to
redirect /mail/inbox/1 to /mail and deliver the mobile code to process the
request.

This is necesary, because from the point of view of the http server, there
is no such thing as a hash uri, it is (in this scenario) for processing by
the client.

I've used this pattern in several implementations. Any feedback would be
more than welcome (especially if, as I do often, I completely missed the
point and suddenly broke the whole web architecture).

Sebastien Lambla



Windows Live Hotmail just got better. Find out more!.