[Bug 34640] Use Protocol.IdentifyAccount to choose accounts' object paths

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=34640

--- Comment #7 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
Comment on attachment 87681
  --> https://bugs.freedesktop.org/attachment.cgi?id=87681
Call IdentifyAccount to get new accounts' names

Review of attachment 87681:
 --> (https://bugs.freedesktop.org/page.cgi?id=splinter.html&bug=34640&attachment=87681)
-----------------------------------------------------------------

::: configure.ac
@@ +220,4 @@
>  AC_DEFINE([TP_DISABLE_SINGLE_INCLUDE], [], [Avoid individual headers])
>  
>  PKG_CHECK_MODULES([GLIB],
> +	[glib-2.0 >= 2.36, gobject-2.0, gmodule-no-export-2.0, gio-2.0])

GTask because life's too short.

::: mission-control-plugins/account.c
@@ +312,5 @@
> +void
> +mcp_account_manager_identify_account_async (McpAccountManager *mcpa,
> +    const gchar *manager,
> +    const gchar *protocol,
> +    GVariant *parameters,

GVariant because I don't want to add any new API that's shaped like dbus-glib.
I should probably add some doc-comments to these.

::: src/mcd-storage.c
@@ +622,5 @@
> +    {
> +      g_task_return_pointer (task, g_strdup (identification), g_free);
> +    }
> +  else if (g_error_matches (error, TP_ERROR, TP_ERROR_NOT_IMPLEMENTED) ||
> +      g_error_matches (error, DBUS_GERROR, DBUS_GERROR_SERVICE_UNKNOWN))

I want to trap ServiceUnknown and either raise a different error or carry on
with the "can't identify" code path, because it seems bad if MC raises
ServiceUnknown in response to a CreateAccount call - that's indistinguishable
from MC itself not existing!

tests/twisted/account-manager/bad-cm.py wants this to return NotImplemented,
which is raised by _mcd_account_set_parameters. The spec says so.

If the CM raises InvalidArgument from IdentifyAccount (which is undocumented,
but reasonable), we'll pass that on as the result of CreateAccount, which is
what the spec says we should do.

If the CM raises InvalidHandle (which is undocumented, but is a reasonable way
to represent "that identifier is bad"), we'll pass *that* on as the result of
CreateAccount, which is undocumented but reasonable.

I'm tempted to document InvalidArgument and InvalidHandle as possible errors
raised by IdentifyAccount, and InvalidHandle as a possible error raised by
CreateAccount (with InvalidHandle having its usual secondary meaning of
"invalid identifier-that-is-equivalent-to-a-handle").

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.