Re: [Evolution-hackers] Account management and keyrings

[Matthew Barnes <mbarnes redhat com>]

On Tue, 2010-11-23 at 23:50 -0500, Matthew Barnes wrote:
> Migration issues aside, since that's already a project unto itself, is
> there any reason why our keyring items can't be as simple as:
> 
>    Description: Evolution data source <<source-uid>>
>    Attributes:  source: <<source-uid>>
> 
> This would make password management damn near trivial.

Some further thoughts along these lines...

Our aging password API in libedataserverui was originally designed for
storing Base-64 encoded passwords in local key files using facilities
provided at the time by libgnome.  When gnome-keyring came along,
support for it was shoehorned into the existing e-passwords API.

Now that we're using the keyring exclusively, the current password API
is deficient on several counts:

  - It blocks.  We have numerous unresolved bugs on file about
    Evolution locking up because gnome-keyring was unresponsive.

  - It returns no status.  It's therefore impossible to know
    whether the password operation was successful or not.

  - It's overly complex.  I posit that all the internal message
    passing in e-passwords.c is no longer necessary.  The keyring
    daemon can already deal with concurrent access.

  - 80% of the API doesn't need GTK+, yet it all lives in
    libedataserverui, which the backend modules can't use.

I'm increasingly of the mindset that we should just scrap most of the
e-passwords API and start fresh.

Last night I fleshed out a new password API for ESources which will live
in libedataserver and can be used by both clients and backends.  It has
both synchronous and asynchronous variants of each operation.


void		e_source_password_store		(ESource *source,
						 const gchar *password,
						 gboolean permanently,
						 gint io_priority,
						 GCancellable *cancellable,
						 GAsyncReadyCallback callback,
						 gpointer user_data);

gboolean	e_source_password_store_finish	(ESource *source,
						 GAsyncResult *result,
						 GError **error);

gboolean	e_source_password_store_sync	(ESource *source,
						 const gchar *password,
						 gboolean permanently,
						 GCancellable *cancellable,
						 GError **error);

void		e_source_password_lookup	(ESource *source,
						 gint io_priority,
						 GCancellable *cancellable,
						 GAsyncReadyCallback callback,
						 gpointer user_data);

gboolean	e_source_password_lookup_finish	(ESource *source,
						 GAsyncResult *result,
						 gchar **password,
						 GError **error);

gboolean	e_source_password_lookup_sync	(ESource *source,
						 GCancellable *cancellable,
						 gchar **password,
						 GError **error);

void		e_source_password_delete	(ESource *source,
						 gint io_priority,
						 GCancellable *cancellable,
						 GAsyncReadyCallback callback,
						 gpointer user_data);

gboolean	e_source_password_delete_finish	(ESource *source,
						 GAsyncResult *result,
						 GError **error);

gboolean	e_source_password_delete_sync	(ESource *source,
						 GCancellable *cancellable,
						 GError **error);

With this in place, the only thing left for e-passwords.c to do is put
up a password dialog.  Although knowing me I'll likely wind up rewriting
that too.

Any strong objections to scrapping e-passwords.c for 3.2?