Shoutbox

I'm currently developing an application that can parse Messenger Plus!-logs and, among other things, make them searchable and more browseable. The problem is that the participants' nickname of a given session is often listed, due to an increadible lenght of the name, with the ending insted of the beginning:

quote:

---

.--------------------------------------------------------------------.
| Session Start: 9. februar 2004                                     |
| Participants:                                                      |
|    CompHeNix (kr_stang@hotmail.com)                                |
|    ...elskap hos søskenbarnet mitt! (alexander_sola@norse-tech.no) |
.--------------------------------------------------------------------.

---

Since the name in the conversation however is listed with the beginning, it's hard for a program to determine which message that belongs to which user:

quote:

---

[22:37:31] CompHeNix: hello
[22:37:41] ALi: http://: Peace

---

I've somehow managed to work out an algorithm that first corresponds the users that can be corresponded, and then just assumes that the remaining messages belongs to the first user without any message corresponded. But this is far from perfect, especially in session with many users chatting at once. And, when no user can be corresponded, the session just becomes one heck of a incomprehensible mess

What I'd like is that the nickname-listing was more consistent - that the nickname in the participant-list was more or less equal to those used in the conversation.

But other than that, the chat-log feature is very good. In my opinion, it is far superior to the logging in MSN Messenger, as this dosen't include the email of the participants, leaving the user-identification nearly impossible.

Keep up the good work!

Just FYI, such a (excellent) log viewer already exists: http://360software.dakotabcn.net/logviewer

Also, the problem you speak of can partialy be "fixed" by the user himself. He need to disable:
Plus! > Preferences > Logging > Truncate contact names longer than...
If the logs are saved without the truncate option, then each nick of each contact can be identified perfectly.

Also don't forget about the many special registry keys for the chatlogs.

But it is true that it isn't easy to get a water-tight detection of the names. But this is simply the way the text logs are and not much can be done by that (unless you use MSN Messenger's XML logs instead). Also because of compatibility reason I don't suspect much will be done. Most people consider the strength of Plus!' logging feature the simplicity it has. But this also comes with a price of course and it's understandable that some people would like it to be more advanced.

Thanks for the reply!

I'm sure you could fix this problem entirely by tweakning the Messenger Plus!'s settings, but the standard-settings would still pose a problem when parsing older logs.

My point is that this would very unlikely be a problem if the user's nickname was truncated the same way as in the log.  And, because most people put a segment they never change in the beginning of their nickname, it would nearly be possible to rely on this completely.

I agree: It is the simplicity of the Messenger Plus!-logs that is its strenght (which is why I use them insted of the MSN Messenger XML-logs), but this problem clearly complicates things. I've even had problems understanding which messange that belongs to who when reading the log myself. I think it woild be much easier if the nicknames used were mostly equal, and not completely different.

And I don't really see what compatibility-problems such a change would result in.

quote:

---

Originally posted by aadnk
My point is that this would very unlikely be a problem if the user's nickname was truncated the same way as in the log.

---

No, it still would be a problem. The nick shown on the conversation lines can also be the custom name from that contact...

quote:

---

Originally posted by aadnk
And I don't really see what compatibility-problems such a change would result in.

---

backwards compatibility problems with existing software to parse the text logs (eg: the Logviewer from Lopardo to name one, and this isn't the only program which uses the text logs)