- From: Ed Summers <ehs@pobox.com>
- Date: Fri, 20 Sep 2013 05:13:35 -0400
- To: Sandro Hawke <sandro@w3.org>
- Cc: David Booth <david@dbooth.org>, Andy Seaborne <andy.seaborne@epimorphics.com>, public-ldp@w3.org
Is it fair to say that SPARQL support isn't currently a requirement for implementing LDP? //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 >>>> >>>> >>> >>> >>> >>> >>> >> > >
Received on Friday, 20 September 2013 09:14:03 UTC