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.
I entirely agree with you at this
point. It could be very helpful to make less dependency on these
kind of libraries.
Yongsheng, do you think we should remove the --keyring command line
parameter in favor of this configuration parameter?
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