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. We can defer the decision by renaming SetPeer to CreatePeer and adding the uniqueness check. Then a ModifyPeer can be added later. -- 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
