On Mon, 2013-02-11 at 14:54 +0000, Counihan, Tom wrote: > > > 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.
Okay, deal. I'll make the change right away. -- 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
