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



On Tue, 2011-04-19 at 18:37 +0200, Milan Crha wrote: 
> Hmm, I think I understand, but I do not see clearly the point. Sometimes
> you do not know if the server requires the authentication, only after
> open, which will deliver (on idle) the "auth-required" signal, which can
> come before the backend notified "open-done", or after, it depends. What
> about offline mode? What about offline server which requires
> authentication when evolution is online? (The CalDAV calendar backend
> deals with that case, somehow.)

Try to think about this from an application author's point of view.  All
the things you're describing should be handled internally to EBookClient
or ECalClient without cluttering up the public API.

What I'm trying to do is think about all the things about ECal and EBook
that have confused me or have been a pain in the ass to deal with over
the years and try and make it easier for application authors like
myself.  And connection management and authentication is a big pain
point with the current API.

Right now we store passwords in GNOME Keyring and we build our own
password dialog when we need to interact with the user.  But that might
not always be the case.  In fact there's a thread right now over on
desktop-devel-list that might change all that really soon.  We need an
authentication API that's generic enough that it won't break as these
technologies and policies change and evolve.

As an application author, all I want to have to do is create some
ECredentials object that that implements the current authentication
policies.  I don't really care what those policies are, and I don't want
to have to deal with them myself.

Then I can pass that ECredentials object any time I need to create a new
EClient.  I just call e_cal_client_new() or e_book_client_new(), pass
the ECredentials object along with some ESource, wait for the callback,
and I'm done.  I can start making calls to the calendar or address book
right away.  If I'm in offline mode, then certain calls will error out.
That's fine.  And if for some the connection needs to re-authenticate
with the server, the EClient already has my ECredentials object so it
can handle everything itself.

That's the experience I'm after.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]