> 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-boun...@syncevolution.org 
[mailto:syncevolution-boun...@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@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution
_______________________________________________
SyncEvolution mailing list
SyncEvolution@syncevolution.org
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to