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. _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
