Re: [Evolution-hackers] Rethinking account management

[Milan Crha <mcrha redhat com>]

On Thu, 2010-12-09 at 11:00 -0500, Matthew Barnes wrote:
> As usual this is turning out to be a bigger job than expected, and I'm
> less confident now that I can get this all done by 2.91.90 but I'm still
> gonna try.  The alternative, since I -really- don't want these XML blobs
> creeping into GSettings even temporarily, is to depend on GConf for 3.0
> and then land this stuff (along with Rodrigo's GSettings branch) early
> in 3.1.  Were it not for the pressure to get everything converted in
> time for GNOME 3.0, I would already be retargeting this for 3.1.

	Hi,
sounds reasonable, this seems to be quite intrusive change, not only for
evo itself, but for everyone using it, so landing in time of .90 might
be rather bad. Apart of that we have enough such changes in sources
already, counting also gtk3, so I'm 111% for postponing to early 3.1.

> libedataserverui
> ----------------
> 
> - All e-passwords functions will simply take an ESource instead of
>   "component" and "key" strings.  Keyring entries will contain the
>   UID of the corresponding ESource instead of URI components (we'll
>   convert existing keyring entries as part of the migration phase).

It would be good to allow also username changing in EPasswords. It's
very unusual to allow only password entering when most applications are
allowing to change both username and password (I'm not aware of any
other with "enter password only" functionality at the moment). It seems
to be related, a bit, thus I'm bringing it here.

Also note one thing which might require a bit rewriting. If I recall
correctly you would use the ESource's UID for password storing. The
thing is that evolution allows setting "auth-method", which is used as
'component'. The advantage of this is that the ESource for calendar can
share password from mailer (while not knowing the parent source/account
at all), because they are using same 'component' and 'key'. So with your
change in the passwords there should be a knowledge to which account is
this ESource tight (which is not always clear right now?), and this
"parent" account should be used instead of the actual ESource, right?

I do not want to complicate things much here, though with the "change
also user name" proposal above it might mean that one wouldn't use
different name for calendar and a different name for mailer with this? I
think we are not using any such approach here anyway, so I'm only
brainstorming here.
	Bye,
	Milan

P.S.: If you'll be changing API, please change also EIterator API, to
not return 'const' pointers from e_iterator_get. We use to forget to
change this release by release :)