1:54 a.m.
-----Original Message-----
From: Patrick Ohly [mailto:patrick.ohly@intel.com]
Sent: Monday, February 11, 2013 2:32 PM
To: Counihan, Tom
Cc: syncevolution(a)syncevolution.org
Subject: Re: [SyncEvolution] SetPeer behaviour.
On Mon, 2013-02-11 at 14:16 +0000, Counihan, Tom wrote:
> 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?
It has to check first and rely on no-one making changes concurrently.
> If the peer exists, but an application looses sight of that, then it
> would not know to clear the cache.
I don't think the middleware should be designed to work around bugs in the
application if it leads to a more complex API, because the complexity itself
breeds bugs.
> 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?
The API is not meant to be used by multiple clients. If we allow that, then we
need to introduce a concept of locking the configuration.
SyncEvolution underneath has it, and it makes writing clients considerably
harder. Therefore I did not include that concept again when designing the
PIM Manager API.
> 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.
We can certainly do that. I just wonder whether we can be really sure that an
app will never want to make config changes.
I don't think we can every be 100% sure, but I would hazard a guess that if this
happens it happens very infrequently. Infrequently enough to suffer the minor heart ache
of removing and recreating the peer.
And thinking about the phone example earlier, we have no guarantee that the 'old'
phone is decommissioned or the new phone doesn't go through some offline refinement
before being reintroduced.
There are so many what-ifs, my leaning it to make it ultra simple and avoid the modify
until one has clear line of sight that it can be utilised effectively.
We can defer the decision by renaming SetPeer to CreatePeer and adding
the uniqueness check. Then a ModifyPeer can be added later.
That would be my leaning.
Warm Regards
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.