ext Sofie Lassborn (TN/EAB) wrote:
Hi Jari,
I have some thoughts about the synchronization in the client of the
notifications of changes and retrieval of documents over XCAP.
Scenario 1: "No xml patching"
The subscription is in the "no xml patching" mode and a notification
containing a link to a document and a new etag “aaa” is received by
the client. Immediately after the notification has been sent out a
change is made to the document by another client and the etag is
updated to "bbb".
The first client makes an XCAP GET request to retrieve the document
and receives a document with etag “bbb” which is different from the
one received in the notification.
The client knows how to use the retrieved document until the
notification with the same etag, "bbb", is received and then when
another notification with etag "ccc" is received the client makes a
new XCAP GET request for this document. If the client in the XCAP GET
receives a document with a different etag than "ccc", the client can
use this document as it is newer than the one with etag "ccc".
-> Scenario 1 has no issues.
Scenario 2: "xml patching"
The subscription is in the "xml patching" mode and a notification
containing a link to a document and a new etag “aaa” is received by
the client. Immediately after the notification has been sent out a
change is made to the document by another client and the etag is
updated to "bbb".
The first client makes an XCAP GET request to retrieve the document
and receives a document with etag “bbb” which is different from the
one received in the notification.
The client ignores all notifications until the notification with etag
"bbb" has been received. When another notification with an etag "ccc"
is received the client uses the included patch on his document. I.e.
the client buffers all notifications that arrives while the client
performs the XCAP GET and when the new document is received it applys
all patches with newer etags than the one in the retrieved document.
-> Scenario 2 has no issues.
Scenario 3: "Aggregation"
The subscription is in the "aggregation" mode and a notification
containing a link to a document and a new etag “aaa” is received by
the client.
The client makes an XCAP GET request to retrieve the document and
receives a document with etag “aaa”.
Several changes are made to the document by another client and the
etag is updated to "bbb" and then "ccc". A new "aggregated"
notification with previous-etag "aaa" and new-etag "ccc" is received
and the client uses the included patches on his document.
-> Scenario 3 has no issues.
Scenario 4: "Aggregation and unlucky timing"
The subscription is in the "aggregation" mode and a notification
containing a link to a document and a new etag “aaa” is received by
the client. Immediately after the notification has been sent out a
change is made to the document by another client and the etag is
updated to "bbb".
The first client makes an XCAP GET request to retrieve the document
and receives a document with etag “bbb” which is different from the
one received in the notification. Another change is made to the
document by some other client and the etag is updated to "ccc".
When the "aggregated" notification with previous-etag "aaa" and
new-etag "ccc" is received the client does not know how to apply these
patches to his document.
-> Scenario 4 has issues.
Possible solution:
In the aggregated notification each change that has been made to the
document is represented by a patch operation.
Each patch operation is specified together with an etag value. The
client will then be able to only apply those changes that has been
made to the document with etag “bbb” and after.
For this to work the schemas for the patch operation elements in
draft-ietf-simple-xml-patch-ops-02 need to be updated with etag
attributes.
right, this is the culprit, but i don't want to disallow aggregation.
In conjunction to the above scenarios I also wonder what the thoughts
with aggregation are. Is the main idea that it should be possible for
the server to "aggregate" several changes on a document into one or
fewer patch elements, i.e. "hide" some of the changes to the client.
This kind of functionality would be very complex to implement and
scenario 4 above would not be solved.
Well i have implemented a really stupid, but very simple logic in
<http://sourceforge.net/projects/xmlpatch>, i.e. there's also an xml
diff utility which produces a diff document of two documents (let's say
initial and updated document). So i'll disagree that it were very
complex to implement (~lk lines of C code). And I'm certain that there
are better ways to implement it...
And btw. even for this "very simple" xcap client i'd propose a similar
model, i.e. you would produce xcap updates based on diffing, at least my
personal experience showed that it was indeed very difficult to combine
internal patching and sending proper xcap requests at the same time ;-).
I mean all possible error cases and keeping a reasonable state machine...
If instead the intention is to "aggregate" several patches in one
notification and to reduce the number of notifications sent then each
patch element could also be linked with the etag of the changed
document and solve scenario 4 above. With the existing schemas this
could be done by having several document elements pointing to the same
document but with different etags and one patch element for each
document element. My proposal, which would produce smaller xcap-diff
documents, is instead to update the schemas for the patch operation
elements in draft-ietf-simple-xml-patch-ops-02 with etag attributes.
Best regards,
Sofie
So we would have etag history in two places ? (and it would mean
updating diff format) and would be somewhat shorter format (and even
more optimizations are possible). However, I still think the proposed
one is the best compromise which allows aggregation. This is definitely
a rare case and thus it is fully _optional_ both for the server and the
client (and as is xml-patching optional). So the non-aggregate mode is
the default mode with patching, but clients may try to use the aggregate
mode as well (which isn't as elegant as one would want, but possible).
Someday, it may be possible to have also e.g. proper versioning in the
xcap server, and then this protocol handshake ugliness disappears with
aggregate mode. We might want to optimize xml-patching mode, but that's
another thing.
thanks,
Jari
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
