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?
> > > 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?
>
> 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?
> 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.
> > > 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.
>
> I just have two questions:
>
> * I think sync-ui uses the template name instead of the server
> name in that option. For me, it stores "ScheduleWorld" instead
> of "scheduleworld", which I used as the server name. This makes
> it difficult to store more than one configuration for one server
> (which is necessary, e.g., for syncing more than one calendar
> with one service). Is this intended?
This is the configuration name. Configuration names became
case-insensitive at some point.
> * In the future, it might be desirable to sync more than one
> service at a time. Would it make sense to make that option a
> list instead of a string?
We haven't thought about the UI for that yet. Perhaps we'll have a
meta-configuration which lists other configs, in which case a single
string would be enough.
--
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
