Re: [Simple] Update to xcap package

[Jonathan Rosenberg <jdrosen at dynamicsoft.com>]

inline.

hisham.khartabil@nokia.com wrote:

> > -----Original Message----- From: ext Jonathan Rosenberg
> > [mailto:jdrosen@dynamicsoft.com] Sent: 19.February.2004 06:48 To:
> > Khartabil Hisham (Nokia-TP-MSW/Helsinki) Cc: CBoulton@ubiquity.net;
> > simple@ietf.org Subject: Re: [Simple] Update to xcap package
> >
> >
> >
> >
> >
> > hisham.khartabil@nokia.com wrote:
> >
> >
> > > I had the use case in my mind that if we have a list that is
> > > shared amongst 100 or even 10000 employees and one modifies it,
> > > then this will result in 100 NOTIFYs. Each then might generate a
> > > GET.
> > OK.
> >
> >
> > > Also for a conference using XCAP, it might be true that there is
> > > one creator, but there could be many privileged users who have
> > > read rights and can subscribe to the changes in the conference
> > > policy.
> > >
> > > I'm not sure if the cost of sending the changes in a NOTIFY as 
> > > opposed to just sending the etag is so great.
> > One thing we need to figure out is the format for the NOTIFY. WHats
> > in the event package at the moment won't work, because there are 
> > many valid results that can be obtained from applying the xcap
> > operations to a document.
>
> I'm sorry, I don't understand what you mean by saying that many valid
> results can be obtained. Can you elaborate?
Sorry for being unclear on it.

Lets say I have a document like this:

<foo>
  <bar id="1"/>
  <bar id="2"/>
</foo>

and I do an xcap addition operation:

PUT http://document/foo/bar[@id="3";]

<bar id="3"/>


XCAP requires that the server create this element such that a GET to the 
same URI returns the same body. However, there are three ways that the 
server could do such an insertion and still meet that definition:

<foo>
  <bar id="3"/>
  <bar id="1"/>
  <bar id="2"/>
</foo>

OR

<foo>
  <bar id="1"/>
  <bar id="3"/>
  <bar id="2"/>
</foo>

OR

<foo>
  <bar id="1"/>
  <bar id="2"/>
  <bar id="3"/>
</foo>


The current xcap-package includes a hash in the notify, to allow the 
client to match what they did against what the server has. I believe 
that, in this hash, ordering of elements and attributes is signficiant. 
As a result, the hash computed by the server might not match the one 
computed by the client, since both client and server did the insert 
separately.

A different "diff" format can be defined which is more precise about 
where the server did the insertion. For any element, specifying its 
parent and previous sibling is sufficient. If we want the hash to remain 
in the notifications, we'd need to define a format like that.

Hope this clarifies.

-Jonathan R.


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

_______________________________________________
Simple mailing list
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple