Bug 42814

Summary: Migrate Butterfly accounts
Product: Telepathy Reporter: Guillaume Desmottes <guillaume.desmottes>
Component: mission-controlAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED FIXED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: enhancement    
Priority: medium CC: cosimo.alfarano
Version: unspecified   
Hardware: Other   
OS: All   
URL: http://cgit.collabora.com/git/user/cassidy/telepathy-mission-control/log/?h=butterfly-migration-42814
Whiteboard: r+
i915 platform: i915 features:

Description Guillaume Desmottes 2011-11-11 04:50:27 UTC
As part of https://bugzilla.gnome.org/show_bug.cgi?id=663829 we want to move away from Butterfly. MC seems to best (or at least the less bad) place to do the butterfly -> haze migration.
Comment 2 Will Thompson 2011-11-14 04:39:58 UTC
(In reply to comment #1)
> Here we go
> http://cgit.collabora.com/git/user/cassidy/telepathy-mission-control/log/?h=butterfly-migration-42814

     release_load_accounts_lock (lad);
+
+    migrate_accounts (account_manager);

I think you want to take an account lock for each account being migrated, and release each one when the migration succeeds or fails; and call migrate_accounts() before this call to release_load_accounts_lock().

account_lock is used to stop the account manager appearing on the bus until all the accounts are loaded up and ready to go. Presumably we want the migration to happen before MC appears on the bus? (With this branch at present, that's not the case.)

It would be nice to annotate the new accounts with some indicator of the account path they replace.
Comment 3 Guillaume Desmottes 2011-11-14 05:17:09 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Here we go
> > http://cgit.collabora.com/git/user/cassidy/telepathy-mission-control/log/?h=butterfly-migration-42814
> 
>      release_load_accounts_lock (lad);
> +
> +    migrate_accounts (account_manager);
> 
> I think you want to take an account lock for each account being migrated, and
> release each one when the migration succeeds or fails; and call
> migrate_accounts() before this call to release_load_accounts_lock().
> 
> account_lock is used to stop the account manager appearing on the bus until all
> the accounts are loaded up and ready to go. Presumably we want the migration to
> happen before MC appears on the bus? (With this branch at present, that's not
> the case.)

Good point. I've done that in a new patch.

> It would be nice to annotate the new accounts with some indicator of the
> account path they replace.

We should either add a Account.Replace (as) or Account.Misc a{sv} property to do so.
Comment 4 Guillaume Desmottes 2011-11-14 05:33:47 UTC
(In reply to comment #3)
> We should either add a Account.Replace (as) 

I meant: Account.Replace (ao)
Comment 5 Guillaume Desmottes 2012-01-05 06:15:32 UTC
Do we really want to know which account it comes from? The only one potentially interested about this information is the logger but it's not going to do any migration anyway. The general idea is that the logger's API should be "protocol + account id" oriented rather than using a specific account. See https://bugs.freedesktop.org/show_bug.cgi?id=42917
Comment 6 Guillaume Desmottes 2012-01-12 07:24:32 UTC
I'd really like to get this branch merged as Butterfly will just not work with Empathy 3.4

We have 3 options:
a) Add Account.Replace (ao)
b) Add Account.Misc a{sv}
c) Decide we don't care and keep the branch as it.

Either way if fine for me as long as we get this thing done.

Note that b) could be useful to also solve the "account id" problem in the logger with IRC: https://bugs.freedesktop.org/show_bug.cgi?id=42917#c12
Comment 7 Guillaume Desmottes 2012-02-14 02:13:34 UTC
Butterfly won't work at all with Empathy 3.4 so my migration branch will be merged before the end of the week (string/ui freeze). The MC one should be as well, but we still have the problem of old logs.

The proper fix is to change logger's API to make it "login id" centric rather than account centric, but that's a pretty big change and I don't see it happening now.

So either we decide to not care about old logs (losing logs is a less bad solution than keeping an unworking TP account) or do a hack to continue displaying them. The only hack I can think of is storing the information about the old account in the new one (Account.Replace or Account.Misc) and use it in liblogger when fetching logs.

Either way is fine for me, MSN has always been a second class citizen in Empathy so maybe loosing logs (from an end user pov, log file won't be deleleted) isn't *that* bad after all.
Comment 8 Simon McVittie 2012-02-14 03:00:11 UTC
(In reply to comment #7)
> So either we decide to not care about old logs (losing logs is a less bad solution than keeping an unworking TP account) or do a hack to continue displaying
> them. The only hack I can think of is storing the information about the old account in the new one (Account.Replace or Account.Misc) and use it in liblogger
> when fetching logs.

I think Account.Replaces or Account.ReplacementFor (an ao, either way) is reasonable. Maiku wants a spec release soon anyway, for Captcha1 (Bug #32125).
Comment 9 Simon McVittie 2012-02-14 05:47:28 UTC
Spec:
http://cgit.freedesktop.org/~smcv/telepathy-spec/log/?h=account-supersedes

tp-glib (the TEMPORARY commit will go away with the new spec):
http://cgit.freedesktop.org/~smcv/telepathy-glib/log/?h=supersedes

MC (based on your branch, migration tested manually):
http://cgit.freedesktop.org/~smcv/telepathy-mission-control/log/?h=butterfly-migration-42814
Comment 10 Guillaume Desmottes 2012-02-14 06:01:05 UTC
All good to me.
Comment 11 Simon McVittie 2012-02-21 08:20:13 UTC
Fixed in git for 5.11.0

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.