- From: Sandro Hawke <sandro@w3.org>
- Date: Fri, 20 Sep 2013 08:02:03 -0400
- To: Ed Summers <ehs@pobox.com>
- CC: David Booth <david@dbooth.org>,Andy Seaborne <andy.seaborne@epimorphics.com>,public-ldp@w3.org
Ed Summers <ehs@pobox.com> wrote: >Is it fair to say that SPARQL support isn't currently a requirement >for implementing LDP? > Yes. It's petty clearly a requirement that LDP be independent of SPARQL. There's an ongoing debate over whether patch should use a subset of SPARQL or something that's not a subset of SPARQL, but no one has suggested full SPARQL. - Sandro >//Ed > >On Fri, Sep 20, 2013 at 12:19 AM, Sandro Hawke <sandro@w3.org> wrote: >> On 09/19/2013 08:30 PM, David Booth wrote: >>> >>> >>> >>> On 09/19/2013 05:54 PM, Sandro Hawke wrote: >>>> >>>> On 09/19/2013 04:39 AM, Andy Seaborne wrote: >>>>> >>>>> >>>>> >>>>> On 18/09/13 21:47, Melvin Carvalho wrote: >>>>>> >>>>>> Hi All >>>>>> >>>>>> Has anyone thought about what happens when 2 or more people want >to >>>>>> access a resource or container at the same time. >>>>>> >>>>>> Could we develop a race condition here? Is there a basic >strategy >>>>>> (such >>>>>> as in unix locking) that could be used to prevent such things. >>>>>> >>>>>> Has anyone considered this case at all? >>>>> >>>>> >>>>> Does the use of etags and of If-* HTTP headers work for the uses >cases >>>>> you have in mind? >>>>> >>>> >>>> While Melvin is consideraing that, a few more comments: >>>> >>>> I think whole-resource locking as in webdav is probably not what we >want >>>> in general, although I guess folks can use it if they want. I >worry >>>> about the extra round-trips and I worry about clients failing to >unlock, >>>> although of course that can be handled by a timeout. But seting a >>>> reasonable timeout will be hard, I imagine. I guess very, very >short >>>> locks (< 1s) would be okay; client will always have to know how to >retry >>>> if/when their lock timed out. >>>> >>>> Ideally, I'd like us to be able to handle high concurrency (10+ >patches >>>> per second to a resource), which I think requires blind patching >(aka >>>> context diffs). A little concurrency can be handled by the If-* >>>> headers. If you get an accidental collisions while using them, one >of >>>> the clients will back off and retry and it'll be fine. But as the >>>> modification rate climbs, backing off becomes problematic. Once the >>>> modification rate exceeds the round-trip-time for some clients, >those >>>> clients become completely unable to modify the resource. The >solution >>>> is for clients to construct patches which work even if the resource >has >>>> changed since they last knew its state (aka blind patching with >context >>>> diffs). I believe that can be done by having the client communicate >to >>>> the server which triples (existing and not-yet-existing) it's >relying on >>>> being unmodified. >>> >>> >>> By sending a SPARQL WHERE clause? >>> >> >> That's certainly one way to do it, yes. So that would need a >bigger >> subset of SPARQL than I proposed in TurtlePatch or Eric proposed at >the >> meeting. How much bigger, I don't exactly know. >> >> -- Sandro >> >> >> >>> David >>> >>>> The If-* headers basically implement optimistic >>>> concurrency control [1] at the per-resource granularity. What I'm >>>> proposing is that we go down to per-triple granularity with OCC to >>>> enable real-time interaction using LDP. >>>> >>>> -- Sandro >>>> >>>> [1] http://en.wikipedia.org/wiki/Optimistic_concurrency_control >>>> >>>> >>>>> Andy >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Received on Friday, 20 September 2013 12:02:10 UTC