26 Sep, 2010, Runter wrote in the 21st comment:
Votes: 0
I prefer just including the read length for the field.
26 Sep, 2010, Runter wrote in the 22nd comment:
Votes: 0
I prefer just including the read length for the field.
26 Sep, 2010, David Haley wrote in the 23rd comment:
Votes: 0
Quote
I misunderstood you; when you said delimiter, I thought you meant for the strings, as opposed to the packets themselves.

I think he did mean the strings; he wants some non-printable character to be used to mark the end of a given packet element.

I don't think this is necessary, and besides, it doesn't completely fix the problem (what if you need to escape that non-printable character?); I think that it should suffice to say that all packet elements should be enclosed in quotation marks, including user names, MUD names, etc., and that key/value pairs should be of the form "key"="value". Escaping would be according to the standard backslash convention. This also has the advantage of making all packets immediately human readable, at the cost of an extra byte per delimited thing (you need one in front and one at the end.)

Of course, this breaks backwards compatibility, but presumably dalet would only do this for clients saying they represent 2.2.
26 Sep, 2010, Runter wrote in the 24th comment:
Votes: 0
Actually, I prefer using an already established format. Especially if we're breaking backwards compatibility.
26 Sep, 2010, Rudha wrote in the 25th comment:
Votes: 0
David Haley said:
Quote
I misunderstood you; when you said delimiter, I thought you meant for the strings, as opposed to the packets themselves.

I think he did mean the strings; he wants some non-printable character to be used to mark the end of a given packet element.

I don't think this is necessary, and besides, it doesn't completely fix the problem (what if you need to escape that non-printable character?); I think that it should suffice to say that all packet elements should be enclosed in quotation marks, including user names, MUD names, etc., and that key/value pairs should be of the form "key"="value". Escaping would be according to the standard backslash convention. This also has the advantage of making all packets immediately human readable, at the cost of an extra byte per delimited thing (you need one in front and one at the end.)

Of course, this breaks backwards compatibility, but presumably dalet would only do this for clients saying they represent 2.2.


I don't think the name of the value is neccesary to put in quotes, since we know that the key names are fairly static, but I do think that putting all strings consistently in quotation marks would be a good thing. It's non-intrusive, it wouldn't break any compatability, and it would be human-readable. As soon as we start putting non-printing characters in the strings that makes it that bit more difficult to determine for debugging if we are sending things correctly.

Maya/Rudha
26 Sep, 2010, David Haley wrote in the 26th comment:
Votes: 0
Quote
I don't think the name of the value is neccesary to put in quotes

I agree that it's not necessary, but I did it for consistency's sake.

Quote
It's non-intrusive, it wouldn't break any compatability, and it would be human-readable.

Technically, it would still break backwards compatibility, because currently user/MUD names are not sent in quotes and old parsers wouldn't know what to do with them. But this is an easy thing to fix in parsers; somebody just has to do it.
26 Sep, 2010, Rudha wrote in the 27th comment:
Votes: 0
That's to do with the parsers trying to cope with the strange implementation of the single word values as opposed to the standard though, and, as you said, pretty easily accommodated for.

Maya/Rudha
26 Sep, 2010, quixadhal wrote in the 28th comment:
Votes: 0
Cratylus said:
Quote
Well, you're right that there's not much to be done. But Crat is more willing to make changes to the server, like fixing the MB line endings. So he might be amenable to only sending out data with quotes, and things like that. The nice thing about that particular change is that it's fully backwards compatible, unless client parsers are utterly brain-dead.


Seems like a good idea. If someone sends me an email it's more likely to wind up on the crat do list.

TBH I think it makes more sense to pick a non-printable character as a delimeter and bump up to 2.2.

-Crat
http://lpmuds.net


Ugh. Non-printable characters make baby Jesus smite people with his debugger! I don't think you really want all the DikuMUD code out there trying to deal with non-printable characters in their network stack… do you?

If you're gonna make that big of a change, you might as well just redesign the protocol to be not brain dead, call it IMC3, and announce that dalet will be upgrading to it on such-and-such a date. Convert or be left behind. THAT would make more sense. :)
26 Sep, 2010, Kline wrote in the 29th comment:
Votes: 0
quixadhal said:
THAT would make more sense. :)


We'll have none of your heathen talk here at MudFights!
26 Sep, 2010, Cratylus wrote in the 30th comment:
Votes: 0
I seriously had no idea the nonprintable chars suggestion would bring out the lulz. They're
not that big a deal on lp's, so I didn't think it would be particularly controversial.

I chucklefully withdraw it.

-Crat
http://lpmuds.net
27 Sep, 2010, David Haley wrote in the 31st comment:
Votes: 0
Cratylus said:
I seriously had no idea the nonprintable chars suggestion would bring out the lulz. They're
not that big a deal on lp's, so I didn't think it would be particularly controversial.

I chucklefully withdraw it.

I 'chucklefully' submit that it has nothing to do with Diku vs. LP vs. NakedMUd vs. whatever, and that you should cheerfully consider that humorous laughs might not be the amusing problem here. :smile:
27 Sep, 2010, Cratylus wrote in the 32nd comment:
Votes: 0
David Haley said:
Cratylus said:
I seriously had no idea the nonprintable chars suggestion would bring out the lulz. They're
not that big a deal on lp's, so I didn't think it would be particularly controversial.

I chucklefully withdraw it.

I 'chucklefully' submit that it has nothing to do with Diku vs. LP vs. NakedMUd vs. whatever, and that you should cheerfully consider that humorous laughs might not be the amusing problem here. :smile:


o snap

bonus lulz
27 Sep, 2010, Cratylus wrote in the 33rd comment:
Votes: 0
So, ok, here's what I'm assimilating from the recent talkings:

- Nonprintable delimeters bad.

- Quotes are already delimeters, why not just use them sanely.

- The only real question is whether *both* keys and vals should be quoted.

So, assuming keys are to be quoted along with vals (which strikes me as wisdom, btw),
that's a fairly drastic format change. If we go that far, perhaps it's worth considering
removing the order-lockeding of headers to packets?

Here's what I mean:

If we're going to change

Quote
You@YourMUD 1234567890 YourMUD!Hub1 ice-msg-b *@* channel=Hub1:ichat text=Hi! emote=0 echo=1


to
Quote
You@YourMUD 1234567890 YourMUD!Hub1 ice-msg-b *@* "channel"="Hub1:ichat" "text"="Hi!" "emote"="0" "echo"="1"


why not

Quote
"source"="You@YourMUD" "number"="1234567890" "routing"="YourMUD!Hub1" "type"="ice-msg-b" "target"="*@*" "channel"="Hub1:ichat" "text"="Hi!" "emote"="0" "echo"="1"


so you can

Quote
"number"="1234567890" "text"="Hi!" "routing"="YourMUD!Hub1" "target"="*@*" "channel"="Hub1:ichat" "emote"="0" "source"="You@YourMUD" "type"="ice-msg-b" "echo"="1"


while you




-Crat
27 Sep, 2010, quixadhal wrote in the 34th comment:
Votes: 0
Careful Crat! You're getting dangerously close to JSON with that kind of free-form, sensible, easy to parse, packet formatting!

I don't think anyone wants to be able to just import/include a JSON API and use json_serialize() or json_deserialize() to form packets directly from structures or objects with NO effort. That's crazy talk!

Quote
{ "source" : { "user" : "You", "mud" : "YourMUD" }, "number" : 1234567890, "routing" : "YourMUD!Hub1", "type" : "ice-msg-b", "target" : "*@*", "channel" : "Hub1:ichat", "text" : "Hi!", "emote" : 0, "echo" : 1 }
27 Sep, 2010, David Haley wrote in the 35th comment:
Votes: 0
Crat: I think that order of packet elements should be utterly irrelevant, yes.

Note that you make an assumption that user and MUD names cannot contain the @ symbol, unless we also amend the spec to say that those should be escaped the usual way (but then that makes parsing those more annoying). This might not be an issue worth caring about.

I don't think we need to use external libraries just to get sane formats, unless somebody feels like finding/producing a JSON lib in LPC. That said, having a format with existing parsers means that languages with access to those parsers can Just Do It whereas people without find themselves in the current situation anyhow of having to Just Write It. (In this case, I would very strongly recommend that the specification be a subset of JSON.)
27 Sep, 2010, Rudha wrote in the 36th comment:
Votes: 0
I'm having difficulty really understanding why "shoehorning" something into TELOPTs would be bad, but shoehorning it into a subset of JSON is okay.

Maya/Rudha
27 Sep, 2010, David Haley wrote in the 37th comment:
Votes: 0
Telnet sub-negotiation requires an entirely different mechanism of parsing the stream – you need to have a functional telnet engine to be able to handle it, you need to intercept the subneg messages and reassemble things, and so forth. A text format can be parsed the same way we're already doing things now. I am not advocating JSON specifically; that was Quix's idea. I just think that if JSON were to be adopted, it be made clear that only a subset must be supported.
27 Sep, 2010, Runter wrote in the 38th comment:
Votes: 0
It wouldn't be shoehorning json. Itd just not be using all of its facilities…which is fine cause you can represent everything done here with them.

Also, as others have already pointed out, there already is a lpc json lib. Why is it more reasonable to expect every language to implement their own parser than only those without?
27 Sep, 2010, Cratylus wrote in the 39th comment:
Votes: 0
Quote
there already is a lpc json lib


If only it were that simple!

That said, even if it were "pretty easy for a dev" to install such stuffs, I think this misses an important point.

Let me take you all the way back to those interminable MSSP wars. One side kept saying "don't be
stupid. telopts are easy". The other side kept saying "that's not the point. It's hard enough to make it
less likely to adopt".

Just Use JSON or some such similar argument may make sense in some strict and logical way. Unfortunately
we are not solving a problem whose variables are all governed by what makes sense. In reality we're
looking to improve a communication medium, something which necessarily brings to the forefront
minimizing the attrition and maximizing the uptake.

As you can see, implementing telopts on muds didn't exactly become the latest craze.

Implementing some kinda public key fappery fails that test pretty hard too.

To be honest, I think my own proposal of everything in quotes and everything as a key-value pair is
pretty faily too in that regard.

So why did I bring it up?

Because we need to find the edges of what can be reasonably done without people throwing up their hands
and saying "screw that, I'm not accommodating that geekfest".

What we have is a protocol whose obvious flaws cause problems and should be fixed. Does that cause some
back compat issues to mitigate? Of course.

Does that mean we ditch the protocol because the fixes generate compat issues? Only if we're going to
let the perfect be the enemy of the good. I care about this discussion in the manner of a guy who actually
runs these things and gets things done. I appreciate thinking out of the box but I think the discussion should
remain realistic.

I mean, if ditching imc2 entirely is the plan, then just use Intermud-3, right? It works, it has an
established userbase, and even has a federation scheme to limit single point of failure!

-Crat
http://lpmuds.net
27 Sep, 2010, David Haley wrote in the 40th comment:
Votes: 0
The change that most minimizes disruption is the one that puts only values in quotation marks. I still think we should make key/value order irrelevant, however we can leave the "packet header" in order (source, number, route, destination, type). Indeed, keys are very unlikely to have spaces in them – and as a stronger statement, it's very unlikely that they will ever need spaces in them (because they are not user-destined data). The order of the initial segment isn't too bad because a simple regex can pluck out all the pieces in order. But key/value order is annoying because some components are optional, etc., so it's easier to just grab them all and stuff them into a str->str map.
Random Picks
20.0/56