Re: multiple changes to resources

hello sandro.

On 2013-09-19 14:54 , Sandro Hawke wrote:
> 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.    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.

what you're proposing is (possibly a set of) PATCH document types for 
RDF, potentially with different patch semantics (and side-effects). that 
would be a great thing to go for from the architectural point of view. 
servers could advertise support for patch media types they support, and 
clients could pick one of the supported ones that they support, and 
think will work well. JSON and XML have started defining PATCH formats 
(JSON has one and another one is underway, for XML one is underway), and 
RDF might want to go that way as well.

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Thursday, 19 September 2013 23:13:56 UTC