Re: hash in WebID - cachability problem

On Fri, Dec 7, 2012 at 8:51 AM, Henry Story <henry.story@bblfish.net> wrote:

>
> 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.
>

+1. That's what I've been advocating since this whole debate started. Good
see we're agreeing and the group is reaching consensus.... let's move on.
This issue can always be re-opened in 6 months or a year if we have more
findings on the whole issue.

Steph.