Am Dienstag, den 18.01.2011, 17:33 +0100 schrieb Patrick Ohly: > On Fr, 2011-01-07 at 14:12 +0000, Patrick Ohly wrote: > > On that occasion I also want to make several other changes which will > > prevent going back: > > 1. split "type" into independent options, to solve > > http://bugs.meego.com/show_bug.cgi?id=1023 > > 2. rename "evolutionsource" to "database", "evolutionuser/password" > > to "backendusername/password", with the old names accepted as > > alias, but not being written to disk > > If I go ahead with this, then strictly speaking, the GetConfig/SetConfig > API will be modified in an incompatible way: I can add translation > between the old config names and the new ones for > evolutionsource/user/password. But the "type" change modifies the > semantic such that a 1:1 translation is no longer possible. > > Frederik, does Genesis depend on these two calls and/or the affected > properties?
No, it doesn’t. Genesis normally just asks for the config names (GetConfigs). I just added the first call of GetConfig to check the ConsumerReady property, but Genesis never uses SetConfig. > Two options: > 1. Rename the properties, keep the GetConfig/SetConfig names as > they are. Clients not using type/evolutionsource/user/password > will continue to work if they ignore unknown properties (as they > should). > 2. Rename the properties, rename GetConfig/SetConfig to > GetConfig1/SetConfig1. Clients not adapted to the change will > fail very visibly. If the client would have tried to work with > the old properties, then this is better than silently touching > the wrong properties. > Genesis wouldn’t be affected, and I don’t know if there are any other D-Bus clients besides Genesis and sync-ui. (Or does the Maemo client now use the D-Bus API?) I must confess that I don’t really understand what the type issue is about, but renaming the GetConfig methods looks not exactly pretty. If you split type into new properties, maybe you could use new names for all new properties and drop the name "type" altogether. That probably would make incompatible clients fail, but would leave the method names intact. Don’t know if that makes sense, was just a thought. Regards, Frederik _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
