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)
> > 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?

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 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.

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
intelligent, though.

> 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?

Yes.

> 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.


_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to