[1.3.x] Client vs hub status messages

[RoLex 1]

Good evening.

So what I'm actually seeing since version 1.3.0 of ApexDC++ and version 2.40 of StrongDC++, is that "undefined" hub protocol messages become client status messages. By "undefined" I mean a protocol message that doesn't have any known syntax, such as main chat message, or doesn't start with a dollar sign. Once the client receives such a message from the hub, it simply inleads it with three asterisks and sends it further as client status message, either in status bar only, or in status bar and main chat, depending on client settings. I'm seeing those kilometer long MOTDs being pushed right into the chat status bar, aswell as all other "undefined" hub messages that come in different length and shapes from different hub softwares; Some are already inleaded by three, two or one asterisks, which does actually represent a hub status message, and definitely not a client status message, others look like NMDC main chat messages but with a missing nick, and few look exactly as every sentence in my message does.

During all my time on DC, I have always known that a client status message, which is called the way it's called because it usually appears in status bar, is a client status message that should come mainly from the client.

Short version of above monologue: Give us back the old school behavior of status messages, because this new one is so damn ugly.

Thank you.

[RoLex 1]

Bump. Any opinions?

[Mek 13]

Well, I agree. I don't see a point why the new behaviour was needed.

[Crise 26]

Well, I agree. I don't see a point why the new behaviour was needed.

It's not about whether it is needed or not... my guess is that it's more about the fact that according to what we know of NMDC (I won't say according to specification, because there isn't an official one for NMDC) this is what clients can expect from hub:

Protocol messages: prefixed with an $ sign... ending with a pipe (|).

Chat messages: prefixed with "<Nick>" without quotes... ending with pipe again.

As you can see messages prefixed with the * sign are not there, technically messages like that are not valid and hubs should not expect client to handle them in one way or another. Regarding these messages it's usually all about /me anyways and as I explained earlier (in another topic) clients send "<Nick> /me message|". to an NMDC hub do (as they should) expect it to come back exactly like that. When some hubsoft choose to alter that clients no longer know what to expect.

Same with nickless messages (also messages begin with an * are nickless as well), in theory they shouldn't exists... and if they did it is very logical for a client to treat them as status/system messages from the hub.

I feel for those (hubs) that rely on clients to implement some special cases of message processing in certain way... that is an extremely bad assumption to make and shows poor judgement on the hub owners (or perhaps the hub developers) part.

[RoLex 1]

Allright, then a feature request. Please make an option along with Show status messages in main chat: Don't show status messages in status bar. One kilometer long MOTD looks really bad in a status bar, and it totally flushes all other previously sent status bar messages. For instance, you can add grayed state to Show status messages in main chat checkbox, which would do exactly what I ask for.

Thank you.

[RoLex 1]

Just found out something else, looks like a bug, and I assume it's related to above issue.

[2010-05-01 01:34:23] *** An existing connection was forcibly closed by the remote host.

[2010-05-01 01:34:23] An existing connection was forcibly closed by the remote host.

[2010-05-01 01:36:31] *** Connecting to *censored*...

[2010-05-01 01:36:31] Connecting to *censored*...

[2010-05-01 01:36:52] *** A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

[2010-05-01 01:36:52] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

This is status message logger. I guess you will have to rewrite the status message handler after all. :)

[RoLex 1]

Bump?!

[Crise 26]

Just found out something else, looks like a bug, and I assume it's related to above issue.

[2010-05-01 01:34:23] *** An existing connection was forcibly closed by the remote host.

[2010-05-01 01:34:23] An existing connection was forcibly closed by the remote host.

[2010-05-01 01:36:31] *** Connecting to *censored*...

[2010-05-01 01:36:31] Connecting to *censored*...

[2010-05-01 01:36:52] *** A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

[2010-05-01 01:36:52] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

This is status message logger. I guess you will have to rewrite the status message handler after all.

Sorry to disappoint you but I can't reproduce the above issue...

[RoLex 1]

Sorry to disappoint you but I can't reproduce the above issue...

Enable both main chat logging and status message logging, and point them both to same file. Or am I misunderstanding something here? :)

[Crise 26]

Enable both main chat logging and status message logging, and point them both to same file. Or am I misunderstanding something here?

Yeah, you are not supposed to point them to the same file... status logging logs the statusbar (of a hub window) and the main chat logging logs the main chat (including status messages printed to/in main chat), Hence the double logging in your scenario