21 Jul, 2009, David Haley wrote in the 22nd comment:
I'm not sure what you're trying to tell me.
It's like you're saying you don't want to improve things more than a little bit. I don't understand your logic. You've already broken compatibility, so there's no point pointing to it as a reason to not improve things more.
It's like you're saying you don't want to improve things more than a little bit. I don't understand your logic. You've already broken compatibility, so there's no point pointing to it as a reason to not improve things more.
21 Jul, 2009, Runter wrote in the 23rd comment:
David Haley said:
I cannot express my objection more strongly; I think it is a very, very bad idea to introduce sloppiness into the protocol and for whatever it's worth I would never back a protocol that did so. From experience with protocols in general, it's just a terrible idea and adds far less benefit than you seem to think it does.
Okay. Noted. Any other complaints?
21 Jul, 2009, David Haley wrote in the 24th comment:
Runter said:
Okay. Noted. Any other complaints?
That depends on what you mean by "Okay. Noted.".
21 Jul, 2009, Runter wrote in the 25th comment:
David Haley said:
I'm not sure what you're trying to tell me.
I'm telling you, as clearly as I can, that you said the stated goal was incompatible with what has been put to paper. I don't know any better way to say it: The goals are met, and it's not incompatible.
21 Jul, 2009, Runter wrote in the 26th comment:
David Haley said:
That depends on what you mean by "Okay. Noted.".
Runter said:
Okay. Noted. Any other complaints?
That depends on what you mean by "Okay. Noted.".
It means I've taken note that David Haley disagrees.
21 Jul, 2009, David Haley wrote in the 27th comment:
Runter said:
I'm telling you, as clearly as I can, that you said the stated goal was incompatible with what has been put to paper.
Is the supposition that those goals are infallible and immutable, or that we can improve things? I still don't understand what point you're trying to make. It's like you're saying "X because I said X".
21 Jul, 2009, Guest wrote in the 28th comment:
Ok, since you all insist on post storming this, I'm going to stop here and respond. If you're 5 pages ahead of me when I'm done, oh well. Jesus people! :P
Human readability is somewhat necessary to see if there's been an error. I can't see many people wanting to debug what happened when "2 14 35 Data="WTF happened" comes over the wire.
There was already an abortive effort made to try this, honestly right now I can't remember why it failed. Probably because I was having trouble with the evils of C-strings and/or not really knowing how the opposite side of an MCCP connection worked. I don't know if there's going to be that much benefit though.
Must have missed something. Variable length packets? Not sure I get what the problem is since not all packets will necessarily need to be large ones.
Only thing I would care much about here is separating elements with something other than spaces. Something the users can't type into their clients. If that's at all possible.
Screw color codes. This is 2009, clients should simply convert their native tagging into ANSI codes and be done with it.
Probably doesn't much matter by the time the message leaves the client. It could just as easily be marked as a plain old chat, yes?
At the risk of generating a shitstorm, don't turn this into another I3. The last time I went anywhere near an I3 network where channels could be generated on the fly, the server had dozens if not over 100 channels that nobody used, just sitting there taking up space for absolutely no good reason. I gather the main point in this is to let people talk to their dev ports over private network channels. There are snippets for that, why waste network resources on something that should be handled locally?
Agreed. I see no sense in allowing clients to spew whatever format they feel like. I could have sworn this was at least part of the argument being made that the protocol needed streamlining, because supposedly there were too many ways to send the data. If the server is strict, then so should the client be strict. Reject anything that's not standards compliant. Otherwise it's just going to be the same big mess all over again. Assuming there ever was a big mess.
David Haley said:
- Reducing bandwidth. This seems incompatible with the apparent goal of making packets human readable. I don't see much need for making packets human readable; although it makes it (only a little) easier to debug, it increases the payload of every message considerably.
Human readability is somewhat necessary to see if there's been an error. I can't see many people wanting to debug what happened when "2 14 35 Data="WTF happened" comes over the wire.
Quote
- Compression. I would do this using plain old MCCP. We know it works, and it's a process that can be initiated or stopped at any point in time.
There was already an abortive effort made to try this, honestly right now I can't remember why it failed. Probably because I was having trouble with the evils of C-strings and/or not really knowing how the opposite side of an MCCP connection worked. I don't know if there's going to be that much benefit though.
Quote
- Variable length packets. Sometimes good, sometimes bad. Unless there's a compelling use-case for them, I would go without. They only add complexity, and make it harder to make short packets.
Must have missed something. Variable length packets? Not sure I get what the problem is since not all packets will necessarily need to be large ones.
Quote
- Packet format.
Only thing I would care much about here is separating elements with something other than spaces. Something the users can't type into their clients. If that's at all possible.
Quote
- Color codes. There should be a very well-defined standard for color codes in IMC packets, that clients can translate to their own color codes if they wish to do so. There should be a well-known convention for escaping color codes in messages. This standard for color codes could simply be ANSI as Crat said.
Screw color codes. This is 2009, clients should simply convert their native tagging into ANSI codes and be done with it.
Quote
- Socials vs. emotes. Drop any kind of explicit social support, make everything emotes.
Probably doesn't much matter by the time the message leaves the client. It could just as easily be marked as a plain old chat, yes?
Quote
- Channels. As others have said, allow creation of channels on the fly, as with IRC for example. The server can specify predefined channels if it chooses to do so. Network admins can override custom created channel policies if necessary.
At the risk of generating a shitstorm, don't turn this into another I3. The last time I went anywhere near an I3 network where channels could be generated on the fly, the server had dozens if not over 100 channels that nobody used, just sitting there taking up space for absolutely no good reason. I gather the main point in this is to let people talk to their dev ports over private network channels. There are snippets for that, why waste network resources on something that should be handled locally?
Quote
- Do not distinguish between packet format for clients and servers. Everybody sends packets the same way. Do *not* allow clients to be sloppy in how they talk to the server. There is a convention, and Thou Shalt Use It.
Agreed. I see no sense in allowing clients to spew whatever format they feel like. I could have sworn this was at least part of the argument being made that the protocol needed streamlining, because supposedly there were too many ways to send the data. If the server is strict, then so should the client be strict. Reject anything that's not standards compliant. Otherwise it's just going to be the same big mess all over again. Assuming there ever was a big mess.
21 Jul, 2009, Runter wrote in the 29th comment:
David Haley said:
Is the supposition that those goals are infallible and immutable, or that we can improve things? I still don't understand what point you're trying to make. It's like you're saying "X because I said X".
Runter said:
I'm telling you, as clearly as I can, that you said the stated goal was incompatible with what has been put to paper.
Is the supposition that those goals are infallible and immutable, or that we can improve things? I still don't understand what point you're trying to make. It's like you're saying "X because I said X".
The point I'm trying to make is exactly what I said. I'll say it again. What we've outlined isn't incompatible with our stated goals. You can claim your ideas are better. And I'm sure your ideas will be considered. by not just me, like everyone elses will be. That doesn't make our results any more incompatible. Maybe you just picked your words wrong. Maybe you just were in a hurry. Maybe now you can't even concede the smallest point. In any event, I don't have any reason to derail this thread with a childish back and forth like this.
21 Jul, 2009, Runter wrote in the 30th comment:
Quote
Agreed. I see no sense in allowing clients to spew whatever format they feel like. I could have sworn this was at least part of the argument being made that the protocol needed streamlining, because supposedly there were too many ways to send the data. If the server is strict, then so should the client be strict. Reject anything that's not standards compliant. Otherwise it's just going to be the same big mess all over again. Assuming there ever was a big mess.
Who wrote the IMC2 format that is inconsistent in format to clients? And yes. There is a big mess. If there's a consensus for a strict format for all clients to the server then I have no problem with that. (It's less work anyways.)
21 Jul, 2009, David Haley wrote in the 31st comment:
Runter, if I've asked you several times what you're trying to tell me, it's not for your or my amusement: I'm really not sure what you're saying or what point you're making. It's not incompatible. And so… what? Does that mean that the ideas are good, bad, neutral, out of the blue? You say that you want to improve bandwidth: ok, you've done so (I'll take your word for it), and then you respond to a suggestion of improving bandwidth further by saying that you already have. What are you trying to say? I understand the literal meaning of your words so there's no point in repeating them: I don't understand what point you're trying to make.
If you get an error so severe that you can't translate it normally, it's unclear to me that human readability will even be on the table.
You'll always need some kind of escape code, one way or the other, so the question is really how often you want to escape things.
Well, the messages are formatted differently, so you'd need to tag it one way as the other.
On-the-fly channels can be destroyed as soon as they're empty, so they wouldn't really be taking up space (think IRC). As for the purpose of channels, I was thinking it was more for setting up a communication channel for people on different MUDs who were talking about something and didn't want it mixed in with e.g. ichat – or the ichat people wanted them off. :tongue:
Samson said:
Human readability is somewhat necessary to see if there's been an error. I can't see many people wanting to debug what happened when "2 14 35 Data="WTF happened" comes over the wire.
If you get an error so severe that you can't translate it normally, it's unclear to me that human readability will even be on the table.
Samson said:
Only thing I would care much about here is separating elements with something other than spaces. Something the users can't type into their clients. If that's at all possible.
You'll always need some kind of escape code, one way or the other, so the question is really how often you want to escape things.
Samson said:
Probably doesn't much matter by the time the message leaves the client. It could just as easily be marked as a plain old chat, yes?
Well, the messages are formatted differently, so you'd need to tag it one way as the other.
Samson said:
The last time I went anywhere near an I3 network where channels could be generated on the fly, the server had dozens if not over 100 channels that nobody used, just sitting there taking up space for absolutely no good reason. I gather the main point in this is to let people talk to their dev ports over private network channels. There are snippets for that, why waste network resources on something that should be handled locally?
On-the-fly channels can be destroyed as soon as they're empty, so they wouldn't really be taking up space (think IRC). As for the purpose of channels, I was thinking it was more for setting up a communication channel for people on different MUDs who were talking about something and didn't want it mixed in with e.g. ichat – or the ichat people wanted them off. :tongue:
21 Jul, 2009, Guest wrote in the 32nd comment:
Runter said:
Who wrote the IMC2 format that is inconsistent in format to clients?
That would be either James Seng or Oliver Jowett.
Quote
And yes. There is a big mess.
That's a matter of some debate, because it's worked just fine for the last 12 years.
Quote
If there's a consensus for a strict format for all clients to the server then I have no problem with that. (It's less work anyways.)
The way I figure it, if you're going to write up a new protocol that is claiming to want to fix the mess, then fix it. Don't just dump the mess elsewhere. Everything should be strict if that's what's really wanted. And I gather from what I'm seeing that strictness is what you'd like to see.
21 Jul, 2009, David Haley wrote in the 33rd comment:
A random question: is there any reason why we're not just using IRC? Have MUD clients implement a subset (or all of) the IRC protocol, and call it even? Why do we need to do all this work to establish a protocol that's basically the same as what IRC already does? IRC already supports tells, private channels, emotes, blablabla.
21 Jul, 2009, Kayle wrote in the 34th comment:
Wow. Shitstorm. Anyway.
I think I lost the point of your argument somewhere. As I became more interested in who was going to resort to name calling first.
If you were arguing about Packet Format, then human readable is the preferred approach for me. I don't want to have to try and debug some whacked out packet that's a bunch of numbers with maybe a string or two. And I'm pretty sure a lot of other people would agree. Is it the most bandwidth saving solution? No. Probably not. Is it the most headache saving solution? Yes. Absolutely.
As per private channels on the fly. This can be done via the multi-tell stuff. And with the Multi-tell stuff, when you're done using it, it goes away, so no more wasted resources tracking a channel not being used.
Spaces in the names.. Eh.. I'm still undecided on this one. I see the point, but at the same time, I see problems with it as well.
I forgot the other points I wanted to respond to. Meh. My Give-a-damn meter was busted earlier with a rather abusive text message calling my wife a whore. So you'll have to excuse me if I sound offensive, or pissed off.
I'll point out that this is supposed to be a Community protocol. Let's try to act like it, shall we? I'm not going to let this spiral into another MSSP.
I think I lost the point of your argument somewhere. As I became more interested in who was going to resort to name calling first.
If you were arguing about Packet Format, then human readable is the preferred approach for me. I don't want to have to try and debug some whacked out packet that's a bunch of numbers with maybe a string or two. And I'm pretty sure a lot of other people would agree. Is it the most bandwidth saving solution? No. Probably not. Is it the most headache saving solution? Yes. Absolutely.
As per private channels on the fly. This can be done via the multi-tell stuff. And with the Multi-tell stuff, when you're done using it, it goes away, so no more wasted resources tracking a channel not being used.
Spaces in the names.. Eh.. I'm still undecided on this one. I see the point, but at the same time, I see problems with it as well.
I forgot the other points I wanted to respond to. Meh. My Give-a-damn meter was busted earlier with a rather abusive text message calling my wife a whore. So you'll have to excuse me if I sound offensive, or pissed off.
I'll point out that this is supposed to be a Community protocol. Let's try to act like it, shall we? I'm not going to let this spiral into another MSSP.
21 Jul, 2009, Runter wrote in the 35th comment:
Samson said:
The way I figure it, if you're going to write up a new protocol that is claiming to want to fix the mess, then fix it. Don't just dump the mess elsewhere. Everything should be strict if that's what's really wanted. And I gather from what I'm seeing that strictness is what you'd like to see.
As long as it Works (Tm) for 12 years it's not a mess anyways. Amiright?
21 Jul, 2009, Runter wrote in the 36th comment:
David Haley said:
I don't understand what point you're trying to make.
That you were wrong? Or maybe you just misspoke? Maybe just once? No, of course not. ;)
21 Jul, 2009, David Haley wrote in the 37th comment:
Runter… seriously?
21 Jul, 2009, Guest wrote in the 38th comment:
Runter said:
As long as it Works (Tm) for 12 years it's not a mess anyways. Amiright?
Well to be perfectly blunt, yes. It's not a mess. It has in fact worked perfectly well with zero complaints in 12 years until people came along wanting to do this with Ruby or Python or Lua or whatever the latest language fad was that apparently couldn't handle the concept of only putting quotes around text with spaces in it.
21 Jul, 2009, Metsuro wrote in the 39th comment:
David Haley said:
A random question: is there any reason why we're not just using IRC? Have MUD clients implement a subset (or all of) the IRC protocol, and call it even? Why do we need to do all this work to establish a protocol that's basically the same as what IRC already does? IRC already supports tells, private channels, emotes, blablabla.
The more I here about IRC the more it sounds exactly like what is being brought up in this change of IMC so why not use it?
21 Jul, 2009, Runter wrote in the 40th comment:
Samson said:
Well to be perfectly blunt, yes. It's not a mess. It has in fact worked perfectly well with zero complaints in 12 years
Well, if the powers-that-be all feel this way I don't see why you would even want an IMC3. So I guess YAIMC may be destined for obscurity as a personal project of mine.
The point still remains, whether you acknowledge it or not, that it isn't incompatible with the stated goals.