http://bugzilla.moblin.org/show_bug.cgi?id=8059
--- Comment #1 from pohly <[email protected]> 2009-11-18 07:48:53 PST --- (In reply to comment #0) > We defined "SetConfig(update=false, {})" so that this removes all properties > referenced by the view and those config nodes which become empty because of > this. The goal was to use this to remove peers and/or sources. > > The problem now is that some of the removed properties may still be in use by > other peers. Should we redefine the API so that only the unshared properties > get removed? > > Suppose that there is only one peer. Selecting that peer for a session and > doing the call above would remove the peer and leave the peer-independent > source settings in place. > > To also get rid of those, we could define that selecting the source set > instead > of a specific peer and then doing the SetConfig() above really removes the > sources. ... and all peers, to be consistent? Another proposal: - if there is only one peer and that peer is to be removed, also remove non-peer properties and nodes - otherwise only remove the per-peer properties This has the advantage that it automatically removes the whole config context, which might be what is expected when only dealing with one peer. The disadvantage is that it removes the source settings even when the user of the API might want to continue using them in his next peer configuration. Because of this disadvantage I prefer a solution where per-peer views only remove the peer properties and non-peer properties have to be removed explicitly via a non-peer view. "global" properties (basically defaultPeer) would never get removed. -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
