Re: [Evolution-hackers] New 'eclient' branch in eds

[Matthew Barnes <mbarnes redhat com>]

On Fri, 2011-04-22 at 19:03 +0200, Milan Crha wrote: 
> Yup, though it'll be (internally - aka in D-Bus) still a signal. This
> request of ECredentials object seems strange to me, because I understand
> the ECredentials as something which actually holds credentials, not
> something what is asking for it something else. Not talking that as  a
> real object it adds, from my point of view, unnecessary overhead and
> complications from simple signal callback.

ECredentials might not be the best name for it, and that may be
confusing the matter a little.  I've been trying to think of a better
name.  EAuthenticator, EAuthenticationPolicy... nothing so far has
really sounded right.  I'm open to suggestions.

The idea though is that what we do now in e-passwords.c -- namely
checking GNOME Keyring for a password and building and displaying our
own password dialog to the user -- is *one possible* implementation of
that simple abstract "get_password" interface that you could pass when
creating EClient objects.

If MeeGo, for example, wanted to handle authentication in a completely
different way -- perhaps not using GNOME Keyring at all or using their
own authentication widget (I'm just making this up) -- they could write
their own implementation and pass *that* when creating EClient objects,
all without disturbing the public API at all.

Maybe ECredentialsProvider is a better name after all.  I don't know
yet.  But does what I'm trying to get at make sense?

Maybe it would help if I wrote something like this for Camel, so I could
point to something concrete and not be so hand-wavy about it.