> -----Original Message----- > From: Patrick Ohly [mailto:[email protected]] > Sent: Monday, February 11, 2013 2:32 PM > To: Counihan, Tom > Cc: [email protected] > 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
