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.

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.

Why? What's the point keeping a duplication of all the logs for an account?

(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.

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.

(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).

(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).

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

(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.

Ok, you convinced me. I agree.

(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.

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

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.

Given that MSN is dead as a protocol, I am closing this report. It's too late to fix this now.