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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
