I think the more important point to make is that the packets shouldn't be messed with by clients trying to treat them as local-encoding-strings (or whatever you want to call them), and not whether or not they contain ANSI color.

The only reason that happens now is because the Freedom client passes the incoming message to the MUD's output handler via whatever the equivalent of send_to_char is. That was done mainly so that the color parsing functions wouldn't need to be done directly by the client. So once the message was passed off, there wasn't much that could be done to prevent the MUD from parsing anything in the message that were color tokens. Not without further modifications to the base code, which are by no means standard even within the same derivative base.

It's all a byproduct of everyone using 15 year old codebases :P

Well, even if it's happening now by accident, the spec should make very clear that clients should not do that. If a client is then "broken", well, that's a bug in the client. The spec itself should make absolutely clear what the expected behavior is.

Well the client isn't doing anything other than taking network tokens and turning them into MUD tokens, according to the color translation file you're using. The client can't be expected to know that those ^ and & tokens mean anything, as you say, so it can't exactly be held responsible for what the MUD does with them once it's received the information to display to the user.

Sorry, I'm not making a distinction at the moment between "the client" and "the MUD" – I consider the thing that sits between the user and the server as "the client". As a user, I expect my client to not modify messages coming from IMC in a way that the IMC protocol does not dictate. A correct IMC implementation should do whatever it takes to prevent the MUD layer from mangling things in unintended ways.

Well then you're advocating a client that has to be tightly integrated into the MUD. And that would go directly against Runter's desire to make the clients easy to install across a wide variety of bases. Introduction of code to twist the MUD's arm into not parsing the color creates a huge mess.

The IMC client and the MUD are two separate entities in my mind, and I think in most other peoples' minds too. So I really can't see how there's away around this without 30 different ways for the network client to talk to the MUD's color parser. Seems a bit counter to the goals.

The problem with just allowing ANSI sequences to be inside the message text, is that it overrides choices that the target MUD server makes, and that the player themselves makes.

If I send "Foo&rbar" via IMC2, I'm wresting control of the output colour away from the intended audience, and saying this will be red. The MUD has the option of not parsing that colour sequence if they don't want you to override their choices. If I send "Foo\eThe problem with just allowing ANSI sequences to be inside the message text, is that it overrides choices that the target MUD server makes, and that the player themselves makes.

If I send "Foo&rbar" via IMC2, I'm wresting control of the output colour away from the intended audience, and saying this will be red. The MUD has the option of not parsing that colour sequence if they don't want you to override their choices. If I send "Foo\e[2mbar", not only am I still taking control of the output, but the MUD can't do anything about it unless they specifically clean and sanitize every bit of text that comes in. In that case, it's my terminal that's doing the transform.

So, you can specify that colour is not allowed in the spec, and filter out such sequences as they come in, or you can say it is allowed, and force that load onto the clients and make them filter it out (or not, as they choose).

As to the why… maybe I want certain channels to always be a given colour. Maybe I'm red-green blind and can't read things if they're the wrong colour. Lots of reasons why colour might be a bad thing, and very few reasons why it's a good thing.

Well, no, what I'm advocating is a "client" that does the right thing as far as the protocol is concerned. I think it's completely shocking that I receive IMC messages that aren't supposed to contain color, but yet the MUD I'm on decides for some completely irrelevant reason – as far as IMC is concerned! – to deform the message.

Regardless, the protocol should specify exactly what the message contents mean, and if the MUD fails to adhere to that, it is buggy. You can argue that it's the MUD's bug and not the IMC layer's bug, I don't really care – the point is that something is not following the spec.

And as I said, in practice nobody actually uses color, so I'm highly unconvinced that we need it in the first place. There are lots of downsides, and the only people who spoke in favor of it haven't really given empirical evidence for how much it is used in practice.

Except that people are free to set up their client/MUD to display IMC messages in a different color. Forcing color upon them removes that control, unless their admin happens to have implement color disabling in the IMC bridge. Don't forget that not all users of IMC are admins or in control of the codebase they're on.

The spec says what the servers and the IMC client layer are supposed to do. That spec does not extend jurisdiction to what the MUD does with the text of the message once the IMC layer has passed it off to be turned into output for the user. That lies outside what the protocol is for. If there's no color in the packet, fine, so be it, but the network has no right to tell the MUD it can't parse what to it are perfectly legitimate color tags. All the network layer should do is tell the mud "here's a message for X, send it to him". Not "here's a message for X, and lay off the color parsing!" because then that's going to require alterations to the color paring layers on all sorts of codebases and you're back in MSSP land with telopt crap nobody wanted to implement.

Samson, your argument is kind of like saying that if you had a browser with a separate HTTP header parsing module, and that header happened to contain XML, then the browser would be free to do random things with that XML despite the HTTP protocol clearly not allowing for that. The browser with that behavior would be doing something highly non-standard at best, and downright broken at worse. I don't think we should start the protocol having already completely abandoned all hope of people actually creating setups that respect the protocol.

Besides, the IMC layer isn't really that separate from the MUD itself. Saying that would be like saying that it would be ok for the MUD to broadcast IMC tells it received to everybody it knew on other networks. That is clearly not following the protocol! Is that ok?

Don't forget that we're already adding a whole new protocol. I think that having MUDs bypass their color parser is the least of our worries in terms of implementation and adoption difficulties! :wink:

I don't think the HTTP+XML browser analogy fits here.

You've got a repository full of codebases here than began their lives with no intermud layer of any sort. Then those "snippets" came along, and suddenly many codebases have the ability to tack one on. A lot of folks I've talked to over the years regard it as a plugin, module, or add-on, but not as native code. I blurred those lines with AFKMud, but that was a design choice on my part. So for me, conforming to the idea that the intermud layer gets to tell the color parser to knock it off isn't a problem. I already accept that I'm distributing the codebase as a single unit.

Getting tons of other codebases to do the same? Not bloody likely. So what's that leave us? The situation we're in now with a mostly universal Merc client. for the sake of my point, I'm obviously assuming nothing else exists, but I think this still leaves quite the problem. Smaug handles color one way. SmaugFUSS handles it another. That's two within one derivative already. Rom doesn't come stock with color. You need an add-on for that too. IIRC, there's 3 of those. And they don't all agree on what tokens to use. Merc has no stock color either, but I think one of the Rom ones will also work there. Don't remember which. ACK I think comes with native color support, with still another set of tokens to process it. Kline can shed more light since he's far more familiar with it than I am. I don't recall if stock Circle comes with color, or if tbaMUD does now, but that's going to be yet another system to account for.

I could probably go on, but I think we all get the idea. The thought of a universal client that knows how to tell each codebase what to do about color parsing when sending messages to the user just flew right out the window. Instead, you're talking about clients being made for each specific base, and that means dozens of them instead of one. I'm not sure that's really a viable way to approach this.

We've got an opportunity to start fresh. You're lamenting the use of 15-year-old code – but we'll be writing fresh code, we'll be making a new start. Why does the poor behavior of old snippets matter? We can write snippets that skip the color parser, we can do all kinds of things.

If we were talking about a simple modification to IMC2, I'd think you were basically right. But that's not what we're doing: we're starting something completely new that will require a complete change of the IMC layer anyhow.

The client is not actually universal and you know that; if it's not written for the appropriate base exactly, changes must be made. We've never been in the situation where a single client is an exact, complete and total fit for every codebase. So I don't think it's reasonable of you to argue as if we were in that situation. (Disregarding the fact that we're going forward here, not moving backward or staying in the same situation.)

Basically your argument appears to be one of inertia of things past, not based on where we're going next.

Regardless you have yet to discuss the reason why we need color in the first place. Do people actually use it? I've really not seen any intentional uses of color. Most of the time, some screwup happens with URLs or something else and color is accidentally introduced, confusing those who see the color and those who don't see the color.

I'm lamenting the use of 15 year old code because, like it or not, people are still using 15 year old code to run their MUDs for the most part. So you're basically saying you're in favor of the write 30 different snippets to use in the 15 year old code. Ok, that's fine. But Runter did at one time mention the desire to produce a "universal" client for the Diku folk, which certainly implied to me that he wanted a one client approach. If that's no longer the goal, perhaps he can clarify that. It would remove a bit of confusion.



I get that. I don't think you're understanding though that this new fancy toy needs to be parts compatible with the old clunky ones people still play with. Involving the color parser makes that job far more difficult than it otta be.



The freedom client is as close to universal as we have, and it doesn't need to be written specifically to suit. It drops into plenty of bases with little or no issue other than the places it needs to add hooks to *ALL* of them for, and those hooks themselves are all the same in the instructions.



Except for the most part, we are. Unless you include the clients for LP and such in that. And if you're going to do that, then no, we don't have a universal client for everyone. That's impossible based on the architecture. I think you know that's not what I'm getting at :)



I don't think it's simply inertia. It's realizing that even though there's a modern client being developed, people are still using clunkers for codebases. What you're asking is basically like wanting to put fuel injection on a car that's designed for carburetors. It could probably be done, but with a lot more effort than should be needed. Unless of course you're offering a cash for clunkers solution to this for people?



It doesn't get used as much over the chat lines as it does for things like stylized who listings. What you're advocating would be just as applicable to saying we should remove all color from all MUDs because users rarely use it intentionally on a chat line. I think that's just absurd myself.

I think that this is all very simple. Do not handle color in any way shape or fashion on the server side. To further enforce that you can either explicitly say that clients should not include color in their outgoing packets, or go so far as to check for ansi and strip it on the server side. The complication that I foresee is that an unlimited number of Muds can have unlimited ways of parsing color. One person might send a rather innocent "$r" or "#r", not intending to colorize a statement, the server will pass it on like a normal message but it happens to be a color code on my mud. Personally, I parse my color at the same time that I output text to the player. So I tried to output that message, everyone would see it as a color! The other option is to strip it out before hand, but then we are missing parts of the intended message. If that is the case, I will have to seperate my color parsing from player output. I do want to colorize specific parts of the message though. So I will have to so something like the following.

incoming_msg_text = "Hey, anyone seen an ampersand r lately? It looks like this &r, cool huh?"

def new_color_parse msg
  return (parse_color("&R[&cICHAT&R] &CFoobar says, ") + incoming_msg_text + '"')
end

Not a big deal really, as long as it's handled properly on the client side.

I guess I'm not getting what your issue is. These "15 year old clunkers" you're so worried about will require a fair bit of work one way or another to get things integrated. Somebody who has enough knowledge to rip out the old thing and stick in a new one is rather likely to have enough knowledge to route text through the colorless output routine instead of the color-enabled routine … are you saying that is not the case? Having a very simple hook that doesn't deal with color seems very easy to me. Is the added work the only thing you're worried about? I guess there's not much point rehashing this endlessly, and clearly you're not understanding my issue any more than I'm understanding yours, so, well, yeah.


Umm.. no… that's not really at all like what I'm advocating. :wink: Besides, I'm not sure we'll be having stylized who listings – and to be honest, I'm not even sure we should! It's a data protocol, not a display protocol for people who want funky who lists.

This is exactly the concern I have. The spec should make it crystal clear that these really should not be handled specially by the client and that message text should be treated verbatim. If a client insists on treating it as color anyhow, that's the client's fault and it's not doing the right thing.

Why not simply ignore the colour -in- the client? Not sure how it's going to be handled at the minute but if it passed through a function that supports colour codes (eg. send_to_char on ROM with Lopes), and the codes exist in the text, you're not going to tell that ROM mud not to parse them.

There's one true constant. Of all these 15 year old code bases, all can support no colour, and I think this should be a deciding factor. It should be something that can be universally accepted among all the codebases, not just some.

I would have to agree with you DH. As long as the server completely ignores color it cannot be doing anything wrong. The error is then either a client that is not following the protocol or a client on a server with a design flaw (like in my situation). I will happily switch up my color parsing, I should have done it properly in the first place.