Hi,
sorry for taking my time... Some answers below, let me know if I missed
any open issues. Frederik, feel free to file bugs in the bugzilla if you
meet interoperability problems with using Genesis and our UI.
Patrick Ohly wrote:
On Sun, 2009-08-16 at 13:16 +0100, Frederik Elwert wrote:
Am Sonntag, den 16.08.2009, 11:06 +0200 schrieb Patrick Ohly:
On Sat, 2009-08-15 at 18:34 +0100, Frederik Elwert wrote:
since SyncEvolution 0.9 ships with the GTK ui, I just tried it out. But
after startup, it tells me that no sync service is configured.
The sync-ui remembers the config that the user has selected for use in
sync-ui in a sync-ui specific gconf key. I suspect that "no sync service
configured" really means "no sync service selected" here.
Ok, that makes sense.
Jussi, should we change the string?
Patrick filed a bug (#5660) and yes, I agree "No sync service selected"
or "No sync service in use" is better.
When I go
into the configuration dialogue, it lists my account data for
ScheduleWorld, except for the password.
The sync-ui assumes that the password is stored in the GNOME keyring. It
currently doesn't work well with existing configurations where the
password is in the config.ini itself. I thought we had an open issue for
it (I found the same problem earlier), but I cannot find the issue.
Jussi, did we fix this?
Yes, I do believe this was fixed so the ui should be able to sync even
with password in the config file. The password isn't visible in the
dialog though (see below).
This is of course way better in means of security. Maybe I should have a
look if I can implement this for Genesis as well (if gnome-keyring is
present, I’d like not to depend on GNOME too much). But at least for
Genesis some kind of migration would be necessary: If a password is
present in the config file, delete it there and set it in the GNOME
keyring.
For that the command line needs to support GNOME keyring first, which it
currently doesn't (#3604). So the current status is:
* if the user changes the password on the sync-ui, save in GNOME
keyring with "-" as password in config.in => command line will
ask for password, breaking Genesis
* if the password is stored in config.ini, don't touch it in
sync-ui
I'm not 100% sure, but I think the second point is the fix that I was
looking. Jussi, do you know why the password is not shown in the second
case?
Password is not currently transmitted via D-Bus... It probably should be
at least when we update the config api. Nothing gets broken though: If
you do set a password with the ui, keyring will be used but otherwise
the password won't be touched.
I don’t have any experience with gnome-keyring, so I’ll have to see how
much work this would be. Is it even possible to access passwords across
applications (like Genesis and sync-ui)? How does syncevolution know
about the password then? Does it look for it in gnome-keyring for
itself, or do I have to pass it to syncevolution somehow?
It is looked up with a set of properties as key:
http://bugzilla.moblin.org/show_bug.cgi?id=2430#c13
Any application with access to the keyring can read and write it.
The secrets do have individual access permissions. Applications can
grant access rights to the secret: so the UI adds the
syncevo-dbus-server binary into the ACL. If it didn't, there would be a
dialog asking the user to approve the access.
This is a bit problematic as a generic UI can't really tell where the
server binary is... My original instinct was that it's not worth it to
add something like this to the API, but the dbus-glib bindings could
have a helper function for adding the server binary to ACL.
This surely is not top priority, but I think it would be nice if one
could run sync-ui and Genesis next to each other. So services set up in
Genesis should work in sync-ui and the other way around. So could anyone
help me find out why sync-ui doesn’t recognise the services I set up
with Genesis? Then I could adjust Genesis’ configuration mechanisms to
be compatible with sync-ui.
You could use the same gconf key to select the active configuration.
Then sync-ui should work right away. Have a look at
/apps/sync-ui/server in gconf-editor.
Ah, that sounds good! It makes sense to store common configuration
options in a common place.
So... should this actually be part of syncevolution config?
- Jussi
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
