[Bug 52231] Storage plugins should be able to create new accounts

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Jul 19 16:42:10 CEST 2012


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

--- Comment #7 from Xavier Claessens <xclaesse at gmail.com> 2012-07-19 07:42:10 PDT ---
(In reply to comment #5)
> If plugins are expected to avoid collisions, please document how they can do
> so. Identifiers of the form goa_234 are not sufficient, because an account name
> created by MC could conceivably collide with that (e.g. the fifth account with
> parameters { "account":  "goa#" } would collide with goa_234, because '#' is
> 0x23).

Not the reason why GOA have names like "goa_<internal id>" is because we can't
save settings on a GOA account. So if 2 accounts have the same manager,
protocol and "account" param (that's very likely if you're using the same email
address for gtalk, wlm and facebook), mcp_account_manager_get_unique_name()
would append a number to uniquify them. But then when MC restart we have no way
to know for sure which account had which suffix, so we could mix accounts and
break stored logs for example.

libaccounts plugin is different because it can store the generated unique name,
so after a restart of MC each account knows what unique name to reuse.

> Identifiers containing a double-underscore are currently safe, so you could use
> goa__234. Or, implement mcp_account_manager_account_exists (you can factor it
> out of get_unique_name) and document that plugins that generate their own IDs
> are responsible for using that to avoid collisions.

I think you're looking too far for the name collision, if the user wants to
shoot himself he has easier ways than that :-) 

But indeed I didn't though about it when writing the GOA plugin, and IMO it's
not worth changing names and breaking all stored logs.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.



More information about the telepathy-bugs mailing list