Re: hash in WebID - cachability problem

On 7 Dec 2012, at 14:03, Nathan <nathan@webr3.org> wrote:

> Henry Story wrote:
>> People who do real implementations of Linked Data in javascript on the browser are telling us this is problematic for them: speed
>> matters in user interface, and the 303 is creating real usability
>> issues.
> 
> To keep this simple:
> 
> 303 responses by RFC 2616 are not cache'd
> httpbis doesn't speak of caching in regard to 303 any more

Ah, that is a pity. Because cached 303s + SPDY would have I think gotten a long way
to resolving the efficiency issues it seems to me. ( With SPDY you could very efficiently
make a large number of entity URI requests that would very efficiently return 303s )

> 
> Pretty much all HTTP tooling everywhere for the last decade has used 2616 and will continue to for quite some time, 303's you may as well assume are not cache'd by clients (*clients = HTTP CLIENTS*).
> 
> The web of linked data utilizes 303 redirects frequently, they are an every day part of what we do and encounter, any tooling which doesn't cater for them is missing half of the data out there.
> 
> Every HTTP URI, with or without a fragment, can send back any status code, including 303, and could easily result in a huge chain of redirects.
> 
> That is to say, WebID cannot preclude 303 responses, it's none of it's concern. WebID is layered on to HTTP, and the dereferencing process never has a fragment in it, so you're never dealing with a fragment at HTTP level.

Agree.

> 
> #frag URIs are great in linked data, very efficient and they keep things clean and simple. Slash-303 URIs exist and can be (and are) used. WebID Protocol requires no extra steps to enable their usage, in-fact it requires many many extra steps to try and preclude them.
> 
> Ultimately we either say that a webid is an HTTP URI, or an HTTP URI with a Fragment - the latter restriction is virtually impossible to impose, but very easy to promote as a KISS approach to WebID w/ Linked Data.

My guess is that there is large agreement with this position. 

Now given that #uris are easier for people to work with, and work better with the web,
it still seems to me that one can promote them with a SHOULD in our spec. 

But my feeling is that even if we do, we should link it to the ISSUE-70 and develop the
best arguments we have on our wiki for each side, so that this can then be resolved
when this is a WG and we have the full W3C process to help us come to a tricky conclusion
like this one. 

In any case a lot of arguments are in flux:
  - the OSX Keychain could be fixed tomorrow
  - the HTTPBis caching of 303s could be re-introduced
  - LDP is evolving
  - we might find other arguments that we have not thought of yet 
    for one side or the other

So it does not look like we can close this completely either. But we can move
on to do the rest of the SPEC. Because I think everybody here agrees that #uris
in the examples should be used, and the descriptions should be done in terms
of them.

   Henry


Social Web Architect
http://bblfish.net/