patch con-neg, was Re: multiple changes to resources

On 09/19/2013 07:13 PM, Erik Wilde wrote:
> 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). 

I think the market would be much better off if we can settle on exactly 
one to Recommend for now, although of course the system should support 
negotiation for others, for use in specialized systems and for the day 
when something way, way better comes along.   But that's already in LDP, 
since it's basically specified by the PATCH RFC.


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

So, having just said this is already in LDP, I have to say I think using 
media types to specify what kind of patch you want, in an RDF world, is 
problematic.    I didn't object to it being in LDP, because it's already 
set by the PATCH RFC, and so it's kind of late to raise a stink.   But 
since you mentioned this, I'll pass on my complaint.  Maybe you know a 
way to make this work.

Imagine I have five styles of patches I want to do.   Like a plain patch 
(no blank nodes), a patch with variables so it can handle blank nodes, a 
patch with sub-patches which are each atomic, a patch with a bit of 
embedded JavaScript for server-side processing, and ... I dunno, a patch 
which can edit lists.  Since I'm working with RDF all around, I find it 
very convenient to express my patches in RDF, so I do that.

Now, what media type(s) do I use for these patches?   I might want to 
serialize my patches in Turtle, or Trig, or JSON-LD, or RDF/XML, or 
N-Quad, or N-Triples.    Each of those has their own media type. Do I 
need to make a new media type for using those with each kind of patch, 
above?  That's 30 new media types, so far.

       -- Sandro

> cheers,
>
> dret.
>

Received on Friday, 20 September 2013 04:31:54 UTC