RE: [Simple] Update to xcap package

[Markus.Isomaki at nokia.com]

Hi,

> Things can get a lot easier and more flexible if we can 
> generally assume that the client has a copy of the data its modifying, 
> so that it can use position to effect insertions and modifications.
> 
> If its not possible, then I think we need to insist on unique 
> attributes or it just gets really out of hand.

It would be really really nice if we would not need to assume that the client always has a fresh copy. While this may the case in most use cases, for instance large lists manipulated by multiple clients become cumbersome.

Markus 

> -----Original Message-----
> From: simple-admin@ietf.org [mailto:simple-admin@ietf.org]On Behalf Of
> ext Jonathan Rosenberg
> Sent: 28 February, 2004 00:22
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: CBoulton@ubiquity.net; simple@ietf.org
> Subject: Re: [Simple] Update to xcap package
> 
> 
> inline.
> 
> hisham.khartabil@nokia.com wrote:
> 
> > 
> >> -----Original Message----- From: ext Jonathan Rosenberg
> >> [mailto:jdrosen@dynamicsoft.com] Sent: 25.February.2004 18:28 To:
> >> Khartabil Hisham (Nokia-TP-MSW/Helsinki) Cc: CBoulton@ubiquity.net;
> >> simple@ietf.org Subject: Re: [Simple] Update to xcap package
> 
> >> Can you provide some motivating cases for 1 and 2? Is there 
> >> something in CPCP?
> > 
> > 
> > In CPCP, you might need to replace a resource in the ACL, or change
> > its access-type from allowed to blocked. The way XCAP is specified
> > now, as we discussed, you need to know the exact position for the
> > resource you want replace (they don't have unique IDs 
> besides the URI
> > they carry). This might be ok, if we always assume that the client
> > has an exact copy of what is on the server. I.e. The client MUST
> > always know the number of elements present and provide the position
> > where to insert the new element as the last element, and therefore
> > knows the exact position of the element to replace.
> 
> This is really an important assumption to verify or reject.
> 
> Things can get a lot easier and more flexible if we can 
> generally assume 
> that the client has a copy of the data its modifying, so that 
> it can use 
> position to effect insertions and modifications.
> 
> If its not possible, then I think we need to insist on unique 
> attributes 
> or it just gets really out of hand.
> 
> 
> > 
> > If that can't be guaranteed then we need 1 and 2 above for CPCP.
> > 
> > My proposal is:
> > 
> > a. If there is an attribute that uniquely identifies an 
> element, then
> > the client uses that to insert and/or replace. b. If there is no
> > attribute that uniquely identifies an element, then the client can
> > only insert an element as the last one in a list.
> 
> In both cases, I think that insertion should take place at the end of 
> the list. This vastly simplifies subsequent position based 
> operations on 
> the document.
> 
> > 
> > It would also be nice if, for a, the client can indicate 
> the position
> > it wants to insert, for hashing reasons.
> 
> This appears hard to do. I was unable to come up with a 
> specific reason 
> it would be needed. What do you mean by hashing?
> 
> -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
> 

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