@Davion

Apparently send_to_char has the exact same flaw that I have recreated in all of my codebases. I'm thinking of just modifying my color parser to handle a few extra cases so that I can flip the parsing on and off for different parts of the same string. :P

Ok, here's the apples and oranges I've been look for. I, and I expect David, have been treating this as a pure DATA protocol, leaving the presentation layer up to the individual clients. Samson appears to be integrating the presentation layer as well.

My thoughts were that things like the who listing should be an array of data, which the client would parse and then construct a text presentation of. At that point, they're free to use whatever colour they want, pad the fields to some width, add leading zeroes, convert times to local timezone, etc…

@Quix - You are right, the client is free to handle all of that as long as the server does not interfere. The problems arise from the differences in muds. For one mud it might be perfectly acceptable to have ampersands and pound signs flung everywhere. In another it make make shit beep and blink pink. Clients will have to be careful in how they handle potentially hazardous material from other muds. Personally I will consider all such external material "Tainted" until I finish having my way with it. :P

I must not have been clear, that's what I was trying to suggest all along – sorry for not being clear on that. :redface:

To be clear: what I want is that the behavior of a given message be predictable. I want to know that sending something will result in everybody seeing what I actually send, not what their MUD happens to garble my message to.

DH - Exactly, which means that clients *CAN NOT* parse color from incoming messages.

Right, and that's why I'd try to emphasize the idea of NOT pre-formatting data in any way before it is sent. Let the protocol specify that the data should be raw, and let the client format it however it likes. If some moron says their username is "&rTurd&Rburgler", they'll have a bit of trouble talking on some games, since it may put their name in colours, which isn't whom you need to send the tell to. :)

I agree (unfortunately) that you can't keep people from doing it, nor can you sanitize it on the server end. Well, you could, but it would be a nightmare to maintain AND be pretty heavy CPU usage as well. All we can do is say "don't do it" in the spec and let the clients decide to trust it, to bypass their colour system, or to scrub it first.

I don't think we need to sanitize it on the server end, the understanding just has to be clear that if people are treating characters in some special way outside of what the IMC specification says to do, then they are introducing a "feature" (i.e. bug) into their IMC implementation.

It does mean that we can (and should) clearly specify formats for things that will result in multiple results.

For example, the who listing… we should probably specify a set of expected columns and a way to delimit or otherwise encapsulate each column as well as each row.

username\tidle-time\nbob\t30\njoe\t0\njoebob\t3600

The idea is to prevent folks from sending a pre-formatted "pretty" who listing, as that might do weird things to other clients. It doesn't really matter HOW you format it, as long as it's a documented format that everyone agrees to. In this case, you might even need the first row to be the column names so the client(s) know which ones they'll care about, and which to toss.

Yes, but the problem here is that you seem to be implying that IMC = MUD because you're saying the entire MUD is the client. I don't buy this being the case and it appears to me that nobody else does either because they're all talking about it in terms of "well we can't help what the MUD does with it". That's pretty much my point. The protocol cannot dictate how the MUD itself handles the raw data you're giving it. It can only dictate that the IMC client is not allowed to convert it into usable color codes for the MUD.

And if you want to treat everything like this is 1995, that's fine, but expect the same kinds of problems to crop up when someone's game turns &rTurd&Rburgler into Turdburgler instead of leaving it alone. I think we're all fairly well aware of the fact that most people will assume IMC is buggy and not their games.

If "&" is their colour symbol, then before sending the text to players in their mud they would first replace all instances of "&" with "&&". They should already have some generic way of doing that, for writing to file and such.

In the original post, Runter mentioned IMC2 converting to and from some universal colour code. That's the approach I would favour, if you really want colour as part of the IMC standard - and if certain muds want colour stripped (or prefer raw ANSI colour codes) they could simply specify that option in their conversion function.

Yes, that's what the IMC2 protocol expects (from what I can tell). Don't really see any problem that would cause me to look for alternatives. If it ain't broke….

What you say makes perfect sense, the only problem is there's no function in place in any of the systems I'm familiar with to do the job of taking & and making it into &&. That would need to be added.



Yes, the color tags for that are specified in the IMC2 protocol documentation. Existing clients already handle translating things using those codes. For the most part it works just fine, but there are instances where once you get the message from the network it ends up falling on its face because the MUD parsed something that shouldn't have been.