Am Freitag, den 11.09.2009, 20:38 +0200 schrieb Patrick Ohly: 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? 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

Frederik Elwert wrote: Yeah, there isn't a common API at the moment, I believe. NetworkManager, Moblin Connman and Maemo ConIC all have different APIs. What we want is fairly simple though and supporting several API shouldn't be that hard. That said, it would make a lot of sense if everyone supported the same API for the simple stuff (iow "am I connected?") - Jussi

Patrick Ohly wrote: Yes, although without any compile time checks. I just connect to org.Moblin.Connman PropertyChanged. Same could be done with NM and ConIC. It'll be one init function and and one signal handler per API. I did a "network abstraction" thingy in geoclue once but I think that was overkill. Is there a downside to just listening to all of the interfaces we care about all the time? -Jussi

I entirely agree with you at this point. It could be very helpful to make less dependency on these kind of libraries. For command line, I think we should use keyring=XXX, but we'll have to do some checks. Could it be possible that a platform includes 2 kinds of keyring libraries, gnome-keyring and KDE-keyring? Cheers, Yongsheng -----Original Message----- From: syncevolution-bounces(a)syncevolution.org [mailto:syncevolution-bounces@syncevolution.org] On Behalf Of Patrick Ohly Sent: Saturday, September 12, 2009 2:39 AM To: SyncEvolution Subject: [SyncEvolution] desktop platform dependencies in syncevo-dbus-server: keyring, network monitoring Hello! 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 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. -- 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 SyncEvolution(a)syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution

On Wed, 2009-09-16 at 07:33 +0100, Patrick Ohly wrote: The Python keyring library apparently solves this also automatically, with the possibility to override it: Configure your keyring lib The python keyring lib contains implementations for several backends, including OSX Keychain, Gnome Keyring, KDE Kwallet and etc. The lib will automatically choose the keyring that is most suitable for your current environment. You can also specify the keyring you like to be used in the config file or by calling the set_keyring() function. http://pypi.python.org/pypi/keyring/ Probably we can look at the code and use the same mechanism to detect the "most suitable" keyring - or link in the Python runtime and call the Python keyring lib (not!). -- 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.

On Wed, 2009-09-16 at 13:50 +0100, Zhu, Yongsheng wrote: This can wait. We aren't even sure whether we will have KDE users in 1.0. I'm discussing this now because I want to get the architecture right and remember what I find about it, not because it has to be implemented immediately. -- 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.