1:16 a.m.
-----Original Message-----
From: Patrick Ohly [mailto:patrick.ohly@intel.com]
Sent: Thursday, February 07, 2013 4:06 PM
To: Counihan, Tom
Cc: syncevolution(a)syncevolution.org
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.