Am Freitag, den 11.09.2009, 20:38 +0200 schrieb Patrick Ohly: > In issue 3604 "command line: use > keyring" (http://bugzilla.moblin.org/show_bug.cgi?id=3604) we debated > whether and where we can depend on desktop platform specific technology > like the GNOME keyring. > > My position was (and still is) that the core SyncEvolution shouldn't be > dependent of something like this if we can avoid it. The result was that > users of libsyncevolution (the UI) must provide methods to read and > write passwords outside of the core configuration. > > So where does that leave the syncevo-dbus-server? My original goal was > to let its clients as the final UI decide where to store passwords, but > Jussi correctly pointed out that a GTK app might very well run inside > KDE with a KDE keyring, so pushing the decision into the UI is no > solution. > > In addition, when we want to run syncs automatically, then the > syncevo-dbus-server needs access to securely stored passwords in the > keyring. So the syncevo-dbus-server executable will depend on the GNOME > keyring. Whether it actually uses the keyring has to be configurable, > because in some situations (running as cron job) the keyring won't be > available. I suggest adding the following server configuration option: > > # Controls password storage. Changing this setting does not > # move the passwords themselves, which has to be done manually. > # > # "config" - store passwords in the SyncEvolution config.ini files > # "GNOME" - GNOME keyring > # default: GNOME (if support was compiled into the binary) > keystore=GNOME
So how is this meant to work from a client-side perspective? Should the client set the server property »keystore« to »GNOME« and add the password to the GNOME keyring by itself? Or does the client simply set the »password« property, and syncevo-dbus-server decides where to store that password? > Yongsheng, do you think we should remove the --keyring command line > parameter in favor of this configuration parameter? > > Network monitoring might be another tricky problem, but in contrast to > password storage, I think it was solved via a freedesktop.org D-Bus API > which works under both KDE and GNOME. We can depend on that on Linux. > Please correct me if I am wrong. I didn’t find anything on fd.o, but I think NetworkManager is commonly used under KDE and GNOME, so it’s DBus interface could be used. But NM is not always present, e.g., some users replace it with wicd, or use old-school config file network configuration. But maybe I missed something. Currently, Genesis uses NM to check for an existing connection before trying to sync. If syncevolution does this in the future, could I remove those checks? Will there be a signal telling the client that the sync was not started due to networking issues? Cheers, Frederik _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
