Logger: import!

[boyska]

Importer is going on!
I just managed to import both OLD and NEW style aMsn logs!
Now, it's time to solve some issues:
- Parser takes the sender "as it is" in the logs: aMsn uses the MSN Name that _can_ change. How should we handle this? We could add a tool to "edit" log entry, so one can select all those nicknames that represent the same person. A pattern-based solution would be great for people that have the nick like this:

Code:

MyNick and_some_other_stuff_here

- Where should we put imported logs? A DB for each parser? This would be simple, but why importing then?? We are importing to have "all in one"! I think that we should import them into the default log db, maybe using a "tag" to identify imported logs (so we could delete it easily, without losing our history)

Now I'll do some refactoring, then I'll send you the code ;-)

[fastguy]

Hi Boyska,

very cool work. I was using aMsn for ages and want to use emesene from now on, with my logs already imported to emesene.

I agree with your comment on having the imports all in the default db. There's no need to have seperation at this stage. We just need a working plugin which can import all our logs into emesene.

Did you see the "im-history" API? That's also interesting concept of storing logs in a central server. I use it now with Miranda on Windows Pidgin on Linux, and with Windows Live Messenger on a remote computer in my father's home. I can see all my logs everywhere from a browser, perfect!

Fast

[boyska]

Thank you fastguy!

But... I have to explain some problems: when importing aMsn (or Mercury) logs, we won't get a "perfect" emesene log, because we lack some informations (i.e.:color of text); this minor issue becomes bigger on chats with 3 or more people, because the chat will be imported twice!
Another problem: if your log format is like this:
MsnNick said: mesagge
the nick could change lots of times, and knowing the email of the contact becomes impossible!
As you can see, import is VERY difficult!

Anyway, assuming a perfect import can be done, we still need to keep imported logs easily recognizable, to allow deleting, updating and so on... mmm, lots of trouble.

im-history is VERY interesting, and we could use it for a better integration, but i don't know much about loading an external library in python (it should be possible, anyway): I'll check, I promise!

[fastguy]

Hi Boyska,

We actually don't need a "perfect" log, we just need the "information". I don't care about the font, the color, the emotion, smileys whatever. Just the text  is good.

Coming to the problem of "nickname" changing. I suggest, when a conversation is parsed for import, the plugin shall first parse all the text and check the "Nickname: " strings. After this, it can present these nicks to the user and let him choose who is who. For example:
Fastguy: hi
James:hi Fast
Fast: so how is life
Boyska: good
Fast: cool
Boyska2: what about you:
Fastguy: not bad.

So the plugin can see this and show me a list of guys, "Fastguy, Boyska, Fast, Boyska2", and give me the option to map them to two users. (excluding chats for the moment). Then I will map it to:
Fastguy, Fast, ... = fastguy (msn_email_unique_id)
Boyska, Boyska2, ... = boyska (msn_email_unique_id)
then the plugin can continue the import.

Just an idea, I'm sure you would have better solutions.

Fast

[boyska]

Hi Boyska,

We actually don't need a "perfect" log, we just need the "information". I don't care about the font, the color, the emotion, smileys whatever. Just the text  is good.

That's true, but I don't like to mix up emesene logs and imported logs: it sounds to me a bit "dirty". So, i propose to "tag" them: this will leave a unified db, being able to recognize imported logs

Coming to the problem of "nickname" changing. I suggest, when a conversation is parsed for import, the plugin shall first parse all the text and check the "Nickname: " strings. After this, it can present these nicks to the user and let him choose who is who.

That's a good idea; i wanted to avoid user interaction, but in this case this is necessary.

PS I started getting documentation about im_history, it shouldnt' be so difficult...

[MrModem]

Sorry bout the bump but, any news on this?

[boyska]

I stopped that work, as it was requiring too much efforts and there wasn't a clear idea of the results I would have liked.
About the im_history, instead, I tried to use it, but merely failed (the documentation was almost zero); i'm still interested in this, anyway