Re: hash in WebID - cachability problem

On 2 Dec 2012, at 20:24, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 12/2/12 12:25 PM, Henry Story wrote:
>> On 2 Dec 2012, at 16:36, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>> 
>>> > On 12/2/12 7:02 AM, Henry Story wrote:
>>>> >> kidehen: neither Linked Data, WebID nor the AWWW are about Tabulator or any other product for that matter. There's no news about the challenges posed to the Tabulator extension and Firefox combo. That's too solution specific to be used as an argument about staying with AWWW and TAG findings re., standards that affect other Web-scale Linked Data endeavors.]
>>> > 
>>> > The record, it should read:
>>> > 
>>> > kidehen: neither Linked Data, WebID nor the AWWW are about Tabulator or any other product for that matter. There's no news about the challenges posed to the Tabulator extension and Firefox combo. That's too solution specific to be used as an argument *against* staying with AWWW and TAG findings re., standards that affect other Web-scale Linked Data endeavors .
>>> > 
>>> > I'll correct the Wiki doc.
>> Thanks Kingsely. I do agree with you that the point you are responding to above has
>> to be filled out in more detail.
>> 
>> But now I wonder how that fits with  Ted Thibodeau's position on the KeyChain [1]. If 
>> I take your argument above and replace Tabulator by OSX Keychain bug
>> ( as shown in this picture http://tinyurl.com/cpbpcqe  ) we get the following:
>> 
>>> >  neither Linked Data, WebID nor the AWWW are about the KeyChain or any other product for that matter. There's no news about the challenges posed to clicking on the SAN of the Apple OSX Keychain. That's too solution specific to be used as an argument *against* staying with IETF findings re., standards that affect other Web-scale Linked Data endeavors .
>> Assuming that the clicking on the OSX keychain SAN URI is not more important than the Tabulator
>> Project, as far as Linked Data goes, then it seems that your argument above (which I think is a good
>> one - and which TimBL needs to address  in more detail than I was able to do) requires you
>> to apply that argument back to your OSX keychain. 
>> 
>> Henry
>> 
>> 
>> [1] see http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/hash#Arguments_Against_Proposal_1
>> namely:
>> [[
>> Ted Thibodeau
>> 
>> 	• The Keychain Access.app in Mac OS X takes any SAN that includes a #, and visually presents it correctly. But when you click on that URI (the textual string of which you cannot select and copy), your browser loads the URI with %23 in place of the # -- e.g., Keychain Access.app displayshttp://twitter.com/TallTed#this locally, but when I click it, my browser (observed with both Firefox and Safari; no reason to think any other would behave differently) tries to load http://twitter.com/TallTed%23this -- which correctly 404s. Now, this is clearly a bug in Mac OS X and/or Keychain Access.app -- but this is a very widely deployed tool which demonstrates the folly of forcing a particular URI pattern for WebID. (This is an argument against both MUST and SHOULD for hash-URI.)
>> ]]
>> 
>> Kingsley added a picture of this KeyChain
>>  https://dl.dropbox.com/u/11096946/WebID/keychain-http-hash-versus-slash-uri-issue-interop-showcase.png
>> 
>> 
> 
> The problem: interoperability with what exists.
> 
> Tabulator: an extension for Firefox and Chrome browsers that enables Linked Data browsing and RWW based CRUD. 

We still have to see what the issues are here. It seems that the cacheability problem pointed out by Nathan
would affect all JavaScript applications, not just tabulator

[[

RFC 2616 says:
"The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable."

HTTPBis says:
"A 303 response SHOULD NOT be cached unless it is indicated as cacheable by Cache-Control or Expires header fields."

Of course most tooling will not cache 303s as it's been a MUST NOT for 13+ years.
]]



> 
> Keychain and Mac Mail: native Mac OS X applications used my Mac OS X users, by default. 
> 
> 
> Tabulator is used by a microscopic minority of end-users, if one seeks to be expansive about the Tabulator user profile. 
> 
> Keychain and Mac Mail: used by majority of Mac OS X users.
> 
> Implications for hash based HTTP URIs:
> 
> Tabulator developers and users: good experience.
> 
> Keychain and Mac Mail users: bad experience due to the fact that both applications convert "#" to %23 when performing HTTP GET operations. 

If you cannot wait for the Apple KeyChain bug to be fixed, and you believe that most of your application users go through this action, then just redirect 

 http://kingsley.idehen.name/dataspace/person/kidehen%23this

to

 http://kingsley.idehen.name/dataspace/person/kidehen#this



> 
> Solution: Don't use SHOULD in the definition of WebID to encourage developers to develop for hash based HTTP URIs. Instead, in line with TimBL's own Linked Data meme, use SHOULD for HTTP URIs. 

There are better solutions:
 - send a bug report
 - redirect the broken url: the user experience will be just right.

> 
> Benefits:
> 
> 1. Mac OS X users (a massive installed base) don't encounter confusing WebID experience when reading emails that have WebID's included in the body (e.g, a mail indicating one's WebID or where it is used to denote an entity), ditto when viewing and then clicking them via Keychain 
> 
> 2. Tabulator developers and users *might* have an inconvenience when they encounter hashless HTTP URIs, but they are a distinct minority user profile

If the tabulator issues are related to JavaScript in the browser then this is the vast number of 
applications on the web that are going to have a problem. 

> 
> 3. Compatibility and consistency with the TimB's own Linked Data meme
> 
> 4. Compatibility with TAG findings.

The TAG does not set standards on 303 redirection cachability issues.

> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	      
> Founder & CEO 
> OpenLink Software     
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/