Re: hash in WebID - cachability problem

+1 from me. I'd like to move forward for now, at least until we finish with
the arguments page.

Andrei


On Fri, Dec 7, 2012 at 10:07 AM, Stéphane Corlosquet
<scorlosquet@gmail.com>wrote:

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