On Do, 2011-06-16 at 12:50 +0100, Jussi Kukkonen wrote:
> >> Now, in the D-Bus interface such an extension of the API is a different
> >> matter. The hashes in GetConfig/SetConfig extend much more naturally to
> >> the additional entries than the command line parameters.
> >
> > Damn, I actually missed this one on the first read -- I had read/written
> > the configs separately and Gabriel no doubt did the same on my que
> > (sorry about that Gabriel). All the better, I'd really rather get rid
> > of those extra calls: using source configs "embedded" in the config hash
> > does sound better.
>
> ...and Patrick just pointed out to me that I'm replying to a already
> scrapped idea. Thunderbird search features are nice but apparently don't
> always present the emails in a logical order :/
>
> So to clear things up:
>
> D-Bus configs do _not_ get a special treatment and UIs do need to handle
> source-configs if they want to be able to support editing webdav
> settings (syncing itself works just by using the local config).
Correct. I gave the rationale somewhere in the monologue with myself ;-)
Basically the arguments were:
* A proper UI needs to understand about CalDAV anyway (for
example, offer folder selection on the remote side).
* The approach of mapping a simplified model in the D-Bus API to
the more complex, real one in the config files would have been
an error-prone hack.
Now that we have the semantic of different peer types, configuring
ActiveSync (which again requires a proper understanding of the config by
the UI) fits nicely into the concept. So I think we took the right
approach.
[shared credentials]
> >> Here are some use cases for this:
> >> * The "google" and "google-calendar" configs will have
> >> "credentials = keyring://server=google" set. In the case of
> >> "google-calendar", both the sync and source configs have that.
> >> That way all three configs use the same username/password
> >> automatically. It forces command line users who do not want to
> >> or can't use a keyring to configure with empty "credentials";
> >> they can't share credentials.
> >> * After configuring via the D-Bus interface, the command line will
> >> automatically enable the right access method for the
> >> credentials. It is no longer necessary to explicitly say
> >> "syncevolution --keyring".
> >> * A future extension would use either a different method or
> >> additional parameters in the URI to define some other
> >> authorization method. The current implementation must throw an
> >> error when running into something it doesn't know.
> >>
> >> Nothing needs to be done in the UI or the command line to support this.
> >> The only changes will be in the current code which talks to the
> >> keyring(s).
> >
> > I mentioned that the source-config password lookup doesn't actually use
> > the keyring at the moment -- if saving credentials in the local config
> > works as well, then this is currently an academic problem that doesn't
> > affect UIs.
>
> ... and this is actually a problem now, as I understand it. When UIs
> save the password in source-config, it gets pushed into keyring, but the
> lookup doesn't actually work.
This is fixed.
Do you agree with the proposed "credentials = URI" approach?
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Pützstr. 5 Phone: +49-228-2493652
53129 Bonn
Germany
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
