27 Sep, 2010, quixadhal wrote in the 41st comment:
Votes: 0
Crat, my reasons for suggesting JSON instead of hand-rolling were for simplicity. No matter WHAT is done, people will have to modify their codebases to make things work. Even just adding quotes, which *should* be backwards compatible… you know some code out there somewhere will break. If it breaks for everyone, we can say ahead of time, this is the new deal. Here are some examples of how to make it work. Do it before Christmas, because that's when the switch gets thrown! If it only breaks for a couple of MUDs, those couple of MUDs may well just quietly disappear, because they can't fix their code and nobody else is having any problems and thus doesn't know anything about it.

Parsing a packet format isn't rocket science, but it is annoyingly tedious. Especially when you're working in plain ANSI C, as the majority of IMC users are. Having to pick things apart using strtok/strcpy/strpscn… not fun. That's why I suggested using a canned protocol, because it's easier to define a struct or class, and call a deserialize() function on a chunk of data, than to fiddle with the parsing code that tries to pick things apart by hand.

I've found that trying to convince people to change things because it's better is pointless. Apathy + Laziness > All. If you say, do it or else, and the "or else" happens, suddenly there's motivation to get off their arse and update. ;)
27 Sep, 2010, David Haley wrote in the 42nd comment:
Votes: 0
Quote
Even just adding quotes, which *should* be backwards compatible… you know some code out there somewhere will break. If it breaks for everyone, we can say ahead of time, this is the new deal.

There's a big difference between some code out there maybe failing, and something actually breaking for everybody.

Quote
If you say, do it or else, and the "or else" happens, suddenly there's motivation to get off their arse and update. ;)

Or not, because they care but not quite enough, and the network is made all the poorer for it.
27 Sep, 2010, Rudha wrote in the 43rd comment:
Votes: 0
You do realise it is not feasible to include JSON in all mud codebases, right? Some of them are pretty entrenched in their current parser schemes and it can be a total pain to reaccomodate them; and if you have to write something new, then you're losing the advantage of simplicity.

I could spin my wheels here and say that the best answer is probably to make the arrangement of keys unimportant and the string values all encapsulated by quotes; I'm not sure why we're talking about JSON and telopts to begin with, I must admit, to solve a problem that can be fixed with simply putting everything in quotation marks. Its like going into a gun store for a pistol and coming out with a bazooka: sure it's going to look sweet and do a hell of a lot more than a pistol, but there'll be a lot of collateral damage and you'll probably look like a big tool. While I'd prefer telopts before json because they have been the standard for … fifteen plus years now, neither are really neccesary. If I were to rewrite it all myself, I'd probably do it something more or less MSDP-ish, but that is defintely not neccesary.

Just … put it all in quotes. It's not hard, and it follows the established protocol. What we would be breaking is deviant behaviours that were programmed to deal with server oddities, and I really dont have a problem with that, because we're correcting (arguably) erroneous behaviour in doing that.

Maya/Rudha
28 Sep, 2010, quixadhal wrote in the 44th comment:
Votes: 0
My point was that if you make ANY changes, you're going to lose people. Most MUD admins are not coders. To them, it doesn't matter if the change requires a total rewrite, or a tiny handful of changes to two printf/scanf functions…. it's all Greek and broken is broken.

Since I was replying to Crat's suggestions, I was pointing out that this
Quote
"source"="You@YourMUD" "number"="1234567890" "routing"="YourMUD!Hub1" "type"="ice-msg-b" "target"="*@*" "channel"="Hub1:ichat" "text"="Hi!" "emote"="0" "echo"="1"

isn't very much of a change from this
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 }

And if you used the latter, you could strip out ALL the hand-written parser code for IMC packet handling and use an API to pack and unpack it.

But…. *shrug*

Every time any discussion gets going about better ways to do things, the fear mongers who predict doom and desolation pipe in and say we don't dare change the Holy Scriptures, because some people won't be able to adapt and will get left behind to bake in the hot sun. As long as fear is the prime motivation, nothing useful will ever get done that would actually improve the situation… so I guess revel in the working brokenness, and be happy. :)

It reminds me of another project that dragged its heels for 10 years, because it would cost millions of dollars and could potentially leave tens of thousands of people without service because they couldn't afford to (or were too lazy to) upgrade… what was that? Oh yeah… digital television signals. That was different though, it actually went through despite all the doomsayers. Think on that for a moment. A government committee-driven project affecting millions is more nimble than a community-driven project affecting a few hundred. Surely this is one of the signs of the apocalypse!
28 Sep, 2010, Rudha wrote in the 45th comment:
Votes: 0
The problem with that is that not all MUDs and programming languages have that API easily available and, as you've said, not everyone has the expertise to make that kind of change. We would essentially be necessitating a fundamental change to the protocol, whereas simply using quotes for all string values is really just asking people to start actually entirely following he established protocol.

Breaking backwards compatability is not always a bad thing and I'm not going to argue that, but there seems little-to-no value gained from using a JSON parsing to offset the amount of work necessary to rework everything.

Maya/Rudha
28 Sep, 2010, David Haley wrote in the 46th comment:
Votes: 0
There's a big difference between making a small, incremental change that isn't that different from what we already have, and then making a change that completely changes the format and the parsing required. If somebody already handles IMC packets with a not-brain-dead parser, they will easily be able to handle everything being in quotation marks – especially if we restrict it to only values, and not the other things. Saying that they should implement or use JSON instead is rather different. I don't understand why this distinction is hard to see: there is a lot of middle ground between doing absolutely nothing to the protocol and then changing it completely. Your arguments are much more condescension than technical, Quix, trying to make it sound like people are afraid or incompetent. You asked me earlier why I want your suggestions to be fleshed out and not imperfect: well, it's because you go off about how people are so scared and incompetent that they can't implement your ideas. So, well, yes, I expect that you at least have the grace to present things that actually make sense. For now, you're just dragging this discussion away from the productive incremental changes that have been presented and trying to turn this into a massive rewrite, for consequences that you won't have to be stuck with later on.
28 Sep, 2010, Rudha wrote in the 47th comment:
Votes: 0
Let's not forget, however, that Quix's suggestion does have merit and it is a somewhat valid solution to the problem; it's easy to see a poster being aggressive or such and responding to that rather than the technical merits or flaws of the suggestion.

I think what's important for Quix to elaborate upon is what he feels we gain from using a JSON type syntax, which would offset the work introduced by reimplementing the protocol using that kind of syntax. I can see the arguement for ease of use, however it's an argument that somewhat falls flat to me when you try to reconcile 'this would be easier to use' with 'this would require a substantial rewrite of existing code for several MUDs'; I'm not sure that Quix fully understands the extent of work involved for MUDs, though he does seem to understand that some MUD admins are going to avoid implementing changes because of the technical challenges.

I think the important thing here is striking a balance between 'difficulty of rewrite' versus 'merits of doing things a different way'; the quotation marks solution, as I'll call it, is probably the most feasible and cost-effective solution because it combines minimal rewrites with an effective solution.

Maya/Rudha
28 Sep, 2010, quixadhal wrote in the 48th comment:
Votes: 0
Quote
For now, you're just dragging this discussion away from the productive incremental changes that have been presented and trying to turn this into a massive rewrite, for consequences that you won't have to be stuck with later on.

So, someone from the Magical Pixie Land will come and rewrite my DikuMUD client for me? I fail to see how I'm not just as "stuck" with the consequences as everyone else…

Quote
I think what's important for Quix to elaborate upon is what he feels we gain from using a JSON type syntax

Hey, I'll give it a shot…

If you were to adopt JSON, you'd be using a well-defined protocol that's already in use out in the wild, and that has libraries available for everything from ASP to Visual FoxPro. That means anyone shouldn't have a problem integrating it into whatever kind of codebase they're using, unless it's a VERY strange one. I know Aidil has already written a JSON module for DGD for the LpMUD folk, and in fact has it working as one method to use when connecting to the I3 network.

If the use of an existing standard isn't good enough, with all the portability and syntax checkers already out there, as I showed above, the syntax is very similar to the orderless key/value pair already mentioned as an idea by Crat. If you don't break out the user and mud into seperate data chunks as I did, the only difference is the use of ':' instead of '=', commas as delimiters between key/value pairs, the fact that numbers aren't quoted (thus letting you know that they are not strings), and the brace pair around the whole thing.

So, adapting any existing parser to do that shouldn't be much more difficult than slapping quotes around the existing key/value pairs. If you can't do the one, you probably can't do the other either (and many MUD admins will fall into this camp).

However, since every IMC implementation I've ever seen handles packets over this socket in a manner totally isolated from the entire rest of the game's parsing, it should ALSO not prove any more challenging to stop parsing it yourself, pass the chunk of string data to a JSON API, and then pick the values you want from the resulting structure that's returned to you.

Looking at the IMC2 freedom client code, an imc_packet structure is already broken out into "from", "to", "type", and "route", and then has a linked lists of other fields which vary based on the type. So, you're already having to parse the packet AND pull values out into fields that you have to traverse. Yes, it's a change, but it's the same basic thing that's already being done. In fact, the client code makes very heavy use of one_argument() to pick apart the packet, and THAT would probably have to change to have a fully key/value setup. It might even have to change just for the proposed quote changes, but maybe not.

For the future, if we were using JSON, adding additional fields, even ones that hold complex strucutres, would only require the end user to add new handlers or case statements to deal with the new fields. The parsing would be unchanged. If the default action on an unrecognized field is to ignore it, clients which made the jump to JSON wouldn't need to upgrade to new functionality unless they wanted to use it, since new packet data would just be parsed and then ignored unless you plucked it out.

Of course, you can do that with unordered key/value pairs too. I'm just saying, removing the order requirement makes the change of the same magnitude as going to an industry standard. If you don't see the value in doing that, you won't see the value in using the standard either.

I could also see a future web client being much easier to build, since JSON is already available in Javascript, PHP, ASP, and perl. With HTML5 and websockets, one could probably make a javascript client that could talk to an IMC server directly. Anyone for an intergossip toolbar? *chuckle*

One other potential benefit, which I hesitate to mention – not beating on the One Network drum here, is the fact that if IMC2 used JSON, the code that handled that network system would be very similar to the code needed to handle the I3 network. Right now, the choice of which network you're on is primarily dictated by what your codebase has available for it. Most LpMUDs tend to use I3 because it uses (text dumps of) native LPC objects as packets. As I said, Aidil already has a JSON version of this functioning, because the two are very similar. Most DikuMUDs tend to use IMC2, because the IMC freedom client is less buggy and more recently updated than the I3 code, and thus that is what's been incorporated into most newer codebases. Having the protocols able to use the same data transport would allow you to write your client code to talk to either side.

Is any of that worth the effort? Would it really be all that much more effort? I listed the 4 changes I saw between the two formats. I may have missed a couple subtle ones. To me, it looks like the same amount of work, even if you stick with a hand-rolled parser. Perhaps it might be worth attempting to write a new I3 parser using the JSON version Aidil has first. If that's not too horrible to do in C, it might be a worthy proof of concept.

I dunno. I'm not a salesman. I'm just trying to point towards what I see as a good solution. You guys are all welcome to look that way, or laugh at me and go about your business.
28 Sep, 2010, David Haley wrote in the 49th comment:
Votes: 0
Quote
So, someone from the Magical Pixie Land will come and rewrite my DikuMUD client for me? I fail to see how I'm not just as "stuck" with the consequences as everyone else…

Did you pay attention to the proposal here? The core proposal was to require that all key/values give their values in quotation marks, instead of sometimes using them and sometimes not (when the value has no spaces). So, if you can already parse values with and without quotation marks, you can parse values with quotation marks.

You are not stuck with the consequences like, say, Crat might be, because you don't run a network and won't have to deal with troubleshooting, convincing people that they need to rewrite stuff to join the network, etc.
28 Sep, 2010, Rudha wrote in the 50th comment:
Votes: 0
If we can think of a way to make a better protocol and someone is willing to do that, I don't see a reason not to take some of the ideas here and play with it if someone feels so inclined as to write it, but I think we need to differentiate between 'writing a new protocol' and 'fixing the existing protocol', however.

Maya/Rudha
28 Sep, 2010, David Haley wrote in the 51st comment:
Votes: 0
Rudha said:
but I think we need to differentiate between 'writing a new protocol' and 'fixing the existing protocol'

QFT.
28 Sep, 2010, quixadhal wrote in the 52nd comment:
Votes: 0
David Haley said:
Quote
So, someone from the Magical Pixie Land will come and rewrite my DikuMUD client for me? I fail to see how I'm not just as "stuck" with the consequences as everyone else…

Did you pay attention to the proposal here? The core proposal was to require that all key/values give their values in quotation marks, instead of sometimes using them and sometimes not (when the value has no spaces). So, if you can already parse values with and without quotation marks, you can parse values with quotation marks.

You are not stuck with the consequences like, say, Crat might be, because you don't run a network and won't have to deal with troubleshooting, convincing people that they need to rewrite stuff to join the network, etc.


Once again, David Haley chooses which context to use when quoting!

You specifically used "stuck with the consequences" to refer to MY proposal of shifting away from a hand-rolled parser to an industry standard, as a way to mock and belittle it. NOW, you are trying to shift the "consequences" to YOUR proposal of just wrapping all values with quotes, in such a way as to make it seem like the work a client author has to do is trivial, at best.

In any case, I never claimed to have the same level of responsibility that Crat has. I don't see YOU having that level of responsibility either, Sir. Unless you are secretly running your own public router that, perhaps, has been hard-coded so as to make non-trivial changes a chore?

Anyways, thanks for taking the time to read the whole of my posting, and choosing to reply to the most trivial part of it. Gotta keep those post counts climing!

FWIW: You (all) might want to consider only enclosing string values in quotes, not numeric values. I suspect several of the Diku parsers probably split on the '=' sign and then use one_argument() to pluck out the value from the right side, without checking for quotes, since they expect a 0 or 1 at that point. If you're really concerned about minimal impact on existing code, looking at a few codebases to see what would and wouldn't break seems to be in order.
28 Sep, 2010, Rudha wrote in the 53rd comment:
Votes: 0
quixadhal said:
FWIW: You (all) might want to consider only enclosing string values in quotes, not numeric values. I suspect several of the Diku parsers probably split on the '=' sign and then use one_argument() to pluck out the value from the right side, without checking for quotes, since they expect a 0 or 1 at that point. If you're really concerned about minimal impact on existing code, looking at a few codebases to see what would and wouldn't break seems to be in order.


While it's not specific to the issue at hand, that's probably one of the most sensible suggestions in this thread. The counter-argument to more extensive rewrites after all is ease of implementation, so it would probably make the issue much clearer and easily if we had a good idea of what is and isn't feasible for different codebases.

I have experience with CircleMUD and NakedMUD, (and some MUSHcode) but not much else, on a programming perspective, so perhaps there are those whom would be better informed to do that.

Maya/Rudha
28 Sep, 2010, David Haley wrote in the 54th comment:
Votes: 0
Quote
You specifically used "stuck with the consequences" to refer to MY proposal of shifting away from a hand-rolled parser to an industry standard, as a way to mock and belittle it. NOW, you are trying to shift the "consequences" to YOUR proposal of just wrapping all values with quotes, in such a way as to make it seem like the work a client author has to do is trivial, at best.

I'm sorry, but I have no idea what you are even talking about…?

If we follow your proposal, the consequences will be far greater in terms of impact present and future than if we just enclose all values in quotation marks. When I said you weren't the one to be saddled with consequences, I was referring specifically to the consequences of your proposal. This has nothing to do with mocking and belittling, and everything to do with real-world, pragmatic consequences that we will have to deal with. By contrast the proposal of enclosing values in quotation marks (which seems sufficient to everybody but yourself) will have a much smaller impact.

Quote
I don't see YOU having that level of responsibility either, Sir.

I wrote and run the logbot for the LPMuds network, so yes, I'm involved.

Quote
Anyways, thanks for taking the time to read the whole of my posting, and choosing to reply to the most trivial part of it. Gotta keep those post counts climing!

I don't see why you find it so necessary to first insult the community for being afraid and incompetent, and then when your suggestion is not embraced immediately, you start personally attacking people who don't agree with you. I didn't address the JSON part of your post because I remain entirely unconvinced and do not find it necessary to keep telling you, especially given how much you seem to object to my posts in the first place. :shrug:
29 Sep, 2010, Runter wrote in the 55th comment:
Votes: 0
This is obviously a discussion about incremental changes to make it more sane without changing much. If you don't establish what your goal really is its hard to have a discussion. Yes, I know its been implied. But the discussion is steadily creeping.

And its really not just a matter of designing something better. Its been done. Its been done using json. Its not just a matter of designing a better server architecture. Its been done. Its truly a matter of adoption. These incremental changes have a high chance of adoption if backwards compatible.
29 Sep, 2010, Runter wrote in the 56th comment:
Votes: 0
40.0/56