> -----Original Message----- > From: Patrick Ohly [mailto:[email protected]] > Sent: Thursday, February 07, 2013 4:06 PM > To: Counihan, Tom > Cc: [email protected] > Subject: Re: [SyncEvolution] SetPeer behaviour. > > On Thu, 2013-02-07 at 15:34 +0000, Counihan, Tom wrote: > > Hi Folks, > > > > In terms of the PIM manager API, specifically: > > > > "void SetPeer(string uid, dict properties) > > > > Adds or modifies a peer. Modifying a peer does *not* affect > > any contact data which might be cached for it. > > " > > And a peer itself characterised as a combination of [protocol, > > transport, address, database, logdir, maxsessions] > > > > I wonder if one modifies some of these keys should the behaviour in > > fact *affect* any contact data which might be cached. > > For instance, if we change the BT address for a previously PBAP > > synchronised phone, and we then come and change the BT address to > > something different for that unique uid, should the contact data not > > be invalidated? > > At the level where peers are configured it is hard to determine which > property changes will invalidate data and whether that is the intended > behavior. Basically this would have to be defined for the specific > implementation and then hard-coded there. > > For example, for the BT address, one could think of a situation where a user > has "My Phone" as peer and then replaces his phone. In this case he > probably has also migrated his data from the old to the new phone and the > cache is still valid. > > I think if the user of the API makes changes where he wants the cache to be > removed, he should remove the peer first. That'll remove the data. A > dedicated > ClearCache(string uid) > method could also be added. > > > Generally, should some properties of a peer be immutable? > > Perhaps I'm miss interpreting the API description? > > No, your interpretation is spot on. The question is which behavior of the > method is desirable.
What is confusing me, looking at this from the Application perspective. I have one API that does both an Add new peer and modify an existing one. The key open this is, is it possible (in corner cases where App looses its brain) that an add new peer is infact a modify existing peer, and how would the application know? If the peer exists, but an application looses sight of that, then it would not know to clear the cache. And does it become more challenging if we have multiple clients - what if both 'add a peer' with unfortunately the same peer id and different parameters for proto, transport.... Could the first in ultimately end up with a peer configuration that is different from what it envisioned? A suggestion if the above make some logic. If one removed the concept entirely of being able to 'modify' a peer, it may make things simpler. SetPeer checks for uniqueness of uid, returns error if that peer already exists. Am I on to something here, or am I the on who's lost his brain :-) Tom. -------------------------------------------------------------- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
