Subject: Re: [Simple] XCAP Issue 5 Interim Summary: selecting multiple ele ments

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 02 Jul 2004 07:03:30 -0400

inline.

Jari Urpalainen wrote:

>>
>>>
>>> Jonathan, I have still this question in another thread, where
>>> idempotency is easily broken during replace (or modify) with single
>>> nodes too. 
>>
>>
>>
>> Different from the above issue? Can you please restate it?
>>
>>
> first you'll have
> <foo a="bar">
> then you want to modify this foo-node with a r-uri
> .../foo[@a="bar"]  and with new content <foo a="foobar">. So we would 
> find a single node and would replace the foo-node with new content and 
> therefore you can't get this new content with the same r-uri anymore. Of 
> course this can be avoided with a request like .../foo[1]. The bad thing 
> here is that the request looks ok (unambiguous) but it is not idempotent 
> and you really need error-checking in the server.

Yes, you need error checking. This request must generate a 409. My point 
was, it is very easy to check for this condition *before* you go and do 
the insert. You just look at the attribute selector in the r-uri 
(@a="bar") and make sure it matches the attributes of the element in the 
body of the request.

> 
> This will happen also with attribute updates like
> put .../foo[@a="bar"]/@a with content "foobar"

Right, good point. This check needs to happen too.

> 
>>> Btw. could someonce explain how DELETE can be idempotent
>>> (rfc2616) ?
>>
>>
>>
>> Its a mystery to me. The second DELETE will generate a 404, since the 
>> previous one did a good job of deleting the resource.
>>
>>>> HTTP PUT operations. So long as you don't need the etag from the=20
>>>> previous operation, this would work. Its bandwidth overhead is 
>>>> almost=20
>>>> the same as multiple insertions that we've been proposing, and the=20
>>>> latency is just about the same thing too.
>>>> =20
>>>
>>>
>>>
>>>
>>> I'd rather say that pipelining could work in some cases, but it is NOT a
>>> solution for doing atomic conditional multi-insertions/deletions which I
>>> still would like to see in XCAP.=20
>>
>>
>>
>> Well, again it comes back to what xcap is trying to do. It is not 
>> meant to be a general XML database protocol. I think its a feature of 
>> the design that it can be pushed towards that by adding features like 
>> multiple-inserts, but really its not our goal.
>>
>> Also, I'll note that if you want a sequence of insertions AND 
>> deletions to be done atomically, you can't do that with the 
>> multiple-inserts appraoch, since that only works with a single PUT (no 
>> DELETE). Thus, you would need proper transaction semantics that allow 
>> you to lock the document, make a bunch of changes, and cancel/rollback 
>> or commit when done, and that is, I think, well beyond what we want here.
>>
> I am not fully following here. In my implementation I will effectively 
> do a locking for the resource before doing any xml-operations, because 
> simultaneous requests (multithreaded implementation) would crash the 
> whole system. So with multi-inserts also the lock is held between all 
> the requests, which will be applied sequentially one by one. After this 
> adding some additional checking is needed to fulfil an unambiguos 
> request, first I'll check that I will still find the same nodes that I 
> inserted and  if that is satisfied I'll check that nodes are not 
> related. To me this looks still very simple and is also trivial to 
> implement.

My point was, with the multiple-inserts technique, it is only allowing 
insertions; you can't also do a delete somewhere in there, and have the 
whole operation locked. That would require proper database-style locking 
mechanisms.

Let me make a proposal. Lets keep multiple inserts out of the base spec. 
I will writeup the multiple inserts as an extension to xcap. Xcap base 
will have a basic capability discovery mechanism, allowing you to check 
what xcap extensions are supported by the server. The client can then 
figure out whether or not it can do the multiple inserts or not. The 
group can then debate the multiple-inserts feature separately as an 
extension. All clients would need to be able to operate against servers 
that didnt do multiple inserts.

Is that OK?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 06 Jul 2004 09:18:29 +0300

ext Jonathan Rosenberg wrote:

>> find a single node and would replace the foo-node with new content 
>> and therefore you can't get this new content with the same r-uri 
>> anymore. Of course this can be avoided with a request like 
>> .../foo[1]. The bad thing here is that the request looks ok 
>> (unambiguous) but it is not idempotent and you really need 
>> error-checking in the server.
>
>
> Yes, you need error checking. This request must generate a 409. My 
> point was, it is very easy to check for this condition *before* you go 
> and do the insert. You just look at the attribute selector in the 
> r-uri (@a="bar") and make sure it matches the attributes of the 
> element in the body of the request.
>
>>
>>> Its a mystery to me. The second DELETE will generate a 404, since 
>>> the previous one did a good job of deleting the resource.
>>>
>>> meant to be a general XML database protocol. I think its a feature 
>>> of the design that it can be pushed towards that by adding features 
>>> like multiple-inserts, but really its not our goal.
>>>
>>> multiple-inserts appraoch, since that only works with a single PUT 
>>> (no DELETE). Thus, you would need proper transaction semantics that 
>>> allow you to lock the document, make a bunch of changes, and 
>>> cancel/rollback or commit when done, and that is, I think, well 
>>> beyond what we want here.
>>>
>> I am not fully following here. In my implementation I will 
>> effectively do a locking for the resource before doing any 
>> xml-operations, because simultaneous requests (multithreaded 
>> implementation) would crash the whole system. So with multi-inserts 
>> also the lock is held between all the requests, which will be applied 
>> sequentially one by one. After this adding some additional checking 
>> is needed to fulfil an unambiguos request, first I'll check that I 
>> will still find the same nodes that I inserted and  if that is 
>> satisfied I'll check that nodes are not related. To me this looks 
>> still very simple and is also trivial to implement.
>
>
> insertions; you can't also do a delete somewhere in there, and have 
> the whole operation locked. That would require proper database-style 
> locking mechanisms.
>
Of course you need proper locking if  you want to use different methods 
sequentially. However, within the same doc you can delete several nodes 
properly.

> Let me make a proposal. Lets keep multiple inserts out of the base 
> spec. I will writeup the multiple inserts as an extension to xcap. 
> Xcap base will have a basic capability discovery mechanism, allowing 
> you to check what xcap extensions are supported by the server. The 
> client can then figure out whether or not it can do the multiple 
> inserts or not. The group can then debate the multiple-inserts feature 
> separately as an extension. All clients would need to be able to 
> operate against servers that didnt do multiple inserts.
>
> Is that OK?
>
> -Jonathan R.
>
That's fine.
BR,
Jari