Bug 42917

Summary: Handle Butterfly -> Haze migration
Product: Telepathy Reporter: Guillaume Desmottes <guillaume.desmottes>
Component: loggerAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED WONTFIX QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: enhancement    
Priority: highest CC: cosimo.alfarano, nicolas
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Guillaume Desmottes 2011-11-14 04:51:37 UTC
As part of https://bugzilla.gnome.org/show_bug.cgi?id=663829#c3 mission-control is going to migrate Butterfly accounts to Haze (bug #42814).

The logger should detect such accounts and migrate the logs as well. Just renaming the directory of the account is enough, no need to change the XML files.
Comment 1 Guillaume Desmottes 2011-11-14 05:36:18 UTC
So, when the logger start or when an account is removed, the logger should check if there is an old butterfly account having the same "id" as a Haze one and then do the migration.
Comment 2 Nicolas Dufresne 2011-11-14 10:15:14 UTC
This is very unusual, logger never moved things around, Someone should potentially make an alias, but I don't think moving it is the way.
Comment 3 Guillaume Desmottes 2011-11-16 01:28:34 UTC
Why? What's the point keeping a duplication of all the logs for an account?
Comment 4 Nicolas Dufresne 2011-11-24 10:42:52 UTC
(In reply to comment #3)
> Why? What's the point keeping a duplication of all the logs for an account?

Not sure where you get the duplicate from. I'm just saying that so far everyone has been strongly against transforming or moving logs around, we simply read them where they are, and log the new one where they should.
Comment 5 Nicolas Dufresne 2011-11-24 10:47:58 UTC
Note, I wouldn't be against logging into protocol_user, instead of cm_protocol_user as we are currently doing. And for the old logs, we could match *_protocol_user from now on.
Comment 6 Guillaume Desmottes 2011-11-25 00:46:24 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Why? What's the point keeping a duplication of all the logs for an account?
> 
> Not sure where you get the duplicate from. I'm just saying that so far everyone
> has been strongly against transforming or moving logs around, we simply read
> them where they are, and log the new one where they should.

Right, make sense. Then I guess this bug should become "Logger should return logs from butterfly when asking logs for a haze/msn account".

(In reply to comment #5)
> Note, I wouldn't be against logging into protocol_user, instead of
> cm_protocol_user as we are currently doing. And for the old logs, we could
> match *_protocol_user from now on.

I don't think that will work. There is no concept of 'user' in Telepathy, most CMs have an 'account' parameter but some don't (Salut for example).
Comment 7 Nicolas Dufresne 2011-11-25 08:04:32 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > Note, I wouldn't be against logging into protocol_user, instead of
> > cm_protocol_user as we are currently doing. And for the old logs, we could
> > match *_protocol_user from now on.
> 
> I don't think that will work. There is no concept of 'user' in Telepathy, most
> CMs have an 'account' parameter but some don't (Salut for example).

What is the correct name of it in the Telepathy vocabulary I don't know, but <Connection Manager Name>_<Protocol Name>_<Account Identification> is what we use to store logs at the moment. I have no idea what the consequences with Salut as I never tested it really. E.g. User/Account ID is the JID in the jabber world. It's possible that Telepathy is missing some protocol attribute to let the logs get stored all together whatever nick name you are currently using (e.g. IRC).
Comment 8 Guillaume Desmottes 2011-11-28 01:05:04 UTC
The log dir depends of the account's path suffix. That's basically an escaped version of what you'd get using 'mc-tool list'.
As you can see we can't infer the login ID from it: http://telepathy.freedesktop.org/spec/Account.html#description
Comment 9 Nicolas Dufresne 2011-11-28 09:16:40 UTC
(In reply to comment #8)
> The log dir depends of the account's path suffix. That's basically an escaped
> version of what you'd get using 'mc-tool list'.
> As you can see we can't infer the login ID from it:
> http://telepathy.freedesktop.org/spec/Account.html#description

We know that already, and we all know that tp_account_parse_object_path() allow extracting information like account_id. Is there something you want to pin-point with this information or you just thought I didn't know ?

All I'm saying is that it would me better to strip off the CM name from the path when use in logging. This would fit in an API break, as it would mean giving up on creating TpAccount object (see bug 26648).

While the account path is friendly for creating a TpAccount, it's totally orthogonal to the notion of logs, which should have been account agnostic from the beginning. (e.g. Logs from MSN account me@msn.com are the same regardless what MSN CM your are using). If the protocol does not have an account id, then the protocol should be the unit for separation.
Comment 10 Guillaume Desmottes 2011-11-29 01:29:49 UTC
Ok, you convinced me. I agree.
Comment 11 Simon McVittie 2012-01-05 07:22:20 UTC
(In reply to comment #9)
> While the account path is friendly for creating a TpAccount, it's totally
> orthogonal to the notion of logs, which should have been account agnostic from
> the beginning. (e.g. Logs from MSN account me@msn.com are the same regardless
> what MSN CM your are using). If the protocol does not have an account id, then
> the protocol should be the unit for separation.

The reason why we didn't do this is IRC. All of my IRC accounts have { "account": "smcv" } in their Parameters, and "smcv" as their NormalizedName and SelfHandle, but one of them is conceptually "smcv on Freenode" and another is "smcv on OFTC" - it's an unusual quirk of IRC that user-visible identifiers are local to a network, rather than being qualified with a domain like they are in XMPP and SIP.

In theory, the same applies to any protocol where there are multiple independent networks each with a flat namespace, but I don't know of any such protocol (maybe SILC?). Most of the protocols with a flat namespace (e.g. ICQ, AIM, Skype, QQ) are proprietary, so there is only one network per protocol, and the protocol name is enough to disambiguate.
Comment 12 Guillaume Desmottes 2012-01-12 07:23:32 UTC
On IRC the real identifier is the IRC network, which is not exposed in TP atm. It is in Empathy but that's a pure UI thing.

If this network were stored in TP, the logger could use that to identify the account without using its path. One way to do it would be to use the Account.Misc a{sv} suggested in https://bugs.freedesktop.org/show_bug.cgi?id=42814#c3
Comment 13 Guillaume Desmottes 2012-01-13 06:30:03 UTC
For the record, empathy-accounts master now set the Service property when creating a new IRC account or modyfing the network of an existing one.
Comment 14 George Kiagiadakis 2016-07-13 12:15:47 UTC
Given that MSN is dead as a protocol, I am closing this report. It's too late to fix this now.

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.