On Tue, 2009-09-15 at 16:04 +0100, Frederik Elwert wrote:
Am Freitag, den 11.09.2009, 20:38 +0200 schrieb Patrick Ohly:
> # 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)
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
The client would set the password property and the poor
syncevo-dbus-server has to figure out the rest.
> Yongsheng, do you think we should remove the --keyring command
> 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
> 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
If we can't determine the network status then we should treat it as
"available". It's save to try a sync and stop it when we run into a
network issue. For automatic syncs we probably should be a bit more
Currently, Genesis uses NM to check for an existing connection
trying to sync. If syncevolution does this in the future, could I remove
Will there be a signal telling the client that the sync
was not started due to networking issues?
We could report this with a suitable status code as sync result which
indicates that the network wasn't available.
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.