A protocol that doesn't take into account the people who might be USING it is worthless. If you're going to go to the effort to make a new protocol to do a better job than the existing ones, you would be foolish to not seek input from BOTH communities. Unless the egos and pride of the people in charge is what's really being developed, of course.

As I stated several times, I'm not trying to merge the networks. I'm trying to make you see that a common protocol that ALL networks can make use of is in everyone's best interest. In other words, don't make it so Diku-centric. Make sure the protocol can be implemented in C, LPC, Ruby, Perl, whatever… with a minimal amount of fuss. Make sure things like the who list format, or the mud info format, aren't done with assumptions that are only useful to the Diku people, or the LP people for that matter.


That's not a reason to disallow channel creation. That's a reason to improve channel handling so that idle channels don't take a significant amount of resources. Use a priority queue and as traffic goes down, shift the channels into the less frequently checked layers of the queue. If no traffic has appeared in an hour, nobody probably cares if notifications of people or muds arriving or leaving are delayed by 5 minutes. If the last subscriber disconnects, remove the entry and recreate it when someone shows up trying to find it again.


Is there any reason not to simply extend IRC's protocol to support things like mud info requests and so forth? I haven't used IRC all that much, so I don't know how extensible it is, but it works perfectly well for channels, tells, and user lists. I'm sure adding IRC client support isn't all that difficult these days.

Well you do appear to be attempting to fix something that's not broken. At least in my opinion. Admins do have opinions you know, and despite the feelings of some people, we even like to express them once in awhile :)

I'm not saying don't do it. I'm just saying that if the reason you want to do it is to fix a perceived mess, don't make another one to replace it with. One of the complaints I'm told you had about this whole thing was the issue with quotes around text in chat packet data coming from servers. Ok, fine. Either the existing spec needs better documentation of such behavior, or there's something that genuinely needs to be fixed. So I can't see any logical reason to then turn back around and say that clients are allowed to be slobs about what they belch toward the server when you've complained about the server belching junk at the clients. If you want consistency, then have it. Don't pretend to have it.

Everything documented here is already finished. I don't plan on ending the project. If it's not adopted, then it's not adopted.



Big difference between allowing users to be lazy with input and allowing the server to be lazy with output. (Which, btw, was never documented properly in IMC2.) That's a whole different debate. With that being said, I think it's safe to say that I will be making YAIMC have a more strict input parser based on the what has been said today by people I respect the opinion of.

That right there is one of the biggest mistakes I ever made in adding to the Freedom client. Those notifications are worthless spam and always have been. I should have taken them right back out when the goober who asked for it disconnected from the network a week later and never came back.

Dang smart people arguments. For me at least, the improvements being made are excellent. I was able to write a standalone client (albeit limited) to work with the new protocol in a few minutes. I've been working on writing a client for the old protocol since I joined mudbytes (I haven't tried THAT hard). But the fact is that it's just so much easier to work with. I think if nothing else it will inspire more people to join the network. Also the *easy* creation of clients for distribution in any language and for any codebase just puts a smile on my face. Don't we all want to consolidate the mudding community?
Samson, there have not been 0 complaints about IMC2. I myself have complained every time I decided to add support into a codebase. =)

Pretty much. Although it's one of the things I would suggest making a subscribable event. Having first encountered this kind of thing in the Amiga's OS, I see notifications and other such things as nothing more than additional channels. If you wanted to see muds bouncing up and down, subscribe to that event channel and log to your heart's content. Same for individual players entering and leaving channels. Just don't make it on by default, since most of the time you won't care.

Users input junk all the time, but in this case the client isn't a user. The client is a program, and there's very little excuse for that program to misbehave just because it can.

And I'm aware that IMC2 isn't as nicely well documented as it probably could be. Xorith went to a great deal of trouble to even get what exists now. Before his effort, there was no documentation on the protocol at all. I don't even think the documentation we have no existed when the first LPC client for IMC2 was developed. That there had to be pain, because they would have needed to do just what Xorith and I did - watch packets over the wire to see how they were formatted. And even then, we could tell immediately that multi-word text messages had quotes, single word messages did not. It wasn't hard to spot. That first LPC client worked just fine with the same methods. So it really boggles me to wonder why that one thing represents such a huge hangup and why it's taken 12 years for someone to say something about it.

And Chris, I said there were zero complaints over the last 12 years. It's only been just recently that these "issues" have been raised and something is being done about it.

That's pretty dismissive for something you acknowledge is a problem. It's an issue for anyone wanting to deal with the client code in any language. Even C.

IMC2 is probably more complex than it needs to be, in fairness, if anything as evidenced by the rather large amount of code it takes to implement it. For something that's really just a chat protocol, you should be able to have a lean and mean implementation that is simple to read and maintain.

I think it makes sense to address these issues and create a protocol that simplifies things, with goals like reducing bandwidth usage and making it easier to implement things. I don't believe it's a good idea to even start thinking about this as anybody's personal project, because this is meant to be a community thing and we all saw what happened when people started treating MSSP as their pet project. I'm not accusing anybody of anything and people should not read into this comment – so please don't. I'm just saying that if a protocol is to be adopted by an entire community, the decision process along the whole way needs to be transparent and inclusive as much as possible.

I think that one reason IMC2 had relatively little complaints is that not that many people implemented their own clients, and (for the most part) the current client is plug-and-play – if you run a Diku. (And, it was included in FUSS etc.) I remember that when I tried using even the standalone, there were far more stumbling blocks than what I would have expected from what's basically just a chat room. It's easy to think that things are obvious if you're been working with them inside and out for 12 years. Yes, maybe problems are only coming to the surface now because of new interest in the protocol – in many ways I think this is actually kind of a good thing, even if it means some hay is being made about it all.


It was mentioned on IMC that IRC gets a bad rap with hosting servers because of an association with hackers, warez, etc., so some explicitly forbid IRC servers on their network. It's too bad, but it's a good reason to avoid it.

Don't put words in my mouth, I said it's a documentation problem, which is fixable by clarifying the docs. Not by throwing the entire protocol out and building a new one because of stumbling over a few quote marks here and there.

Considering one of your own stated goals is to simply things and make them more consistent, your bizzare assertions that clients are allowed to be sloppy just don't fit. So you're not even following the logic you yourself used to declare IMC2 broken enough to need to be replaced.




Part of the reason there's such a large amount of code is because the client is also implementing channel and server administration functions which I have said for awhile now should really be done through direct server logins. That could and should be solved at the server level. It would eliminate a huge amount of client side code that's simply not needed, that currently only exists because it was convenient to the network admins who ran things 8 years ago. Dropping all that junk would make things far less bloaty.

Something else which wasn't brought up yet that I could see. Is the new protocol going to deal with anything like sha256? That's another area that does cause some problems that may or may not make it worth continuing to use. I don't know that we really need to be worried about securing connections to the network any more than they are with irc, aim, etc. If someone is determined enough to sniff the connections between client and server, there's likely already a much larger problem to worry about.

You may not like me thinking of it as my personal project—But it is. It very well may not be adopted by anyone and in that case it remains my personal project. The community can adopt whatever protocol they feel is best. (Or they can keep what they already have.) I never have claimed this is IMC3. I see merits in my project. I offer it for consideration. That's all at this time.

Okay. Well, I think this is precisely why you don't see any merit in any rewrite. You think there are no problems. Nobody has had any complaints in 12 years, or so you say, and the only concession you're willing to make is someone didn't document it properly for people wanting to write their own clients. I'm sure I'm still putting words in your mouth so you're free to correct me.

And if we want to start talking about merits in rewrites—Even without changing any protocol—The server and client code as it stands is pretty much rubbish. Would you support a rewrite of those?

Well, we can just stop this nonsense right now: The server will receive completely uniform input. I concede the point. That doesn't fix IMC2, though.

Well why precisely should I concede the protocol is broken when 12 years of non-brokenness says otherwise? If you think this is bad, I'd really hate to see how much of a head explosion you'd have over trying to make sense of the I3 protocol. So yes, I suppose the only concession I am willing to make is that the docs aren't as good as they could be. I hate writing documentation. So did Xorith. But it got done because people wanted it, and there were folks at the time interested in writing their own clients. A few people did, and they had no trouble adapting. The CoffeeMUD client was written after the specs were published, and Bo seems to have had no trouble grocking the quotes with spaces thing.

I more or less expected a hostile reaction to suggesting that a protocol rewrite is unnecessary, and my gut didn't fail me there because that seems to be exactly what I got out of bothering to chime in. You also appear to be taking my indifference/opposition to be an assumption that it won't be adopted. While I may have a say in that, it's not just my decision that matters in this.

Apparently you also seem to have interpreted my desire to not bother upgrading my own client as some kind of bad thing. You have a solution to countering lazy bastards like me who simply don't want to spend the time. Drop support for IMC2 on the new server. That would pretty much force people to decide, yes?



I don't know if I'd go so far as to call them rubbish, but yes, they could use a good cleanup and rewrite. I'm not going to claim I know the best methods for writing the code. I leave that to other people to be elitist about. But as I said to David, the single best thing that could be done is to move channel and server administrative functions out of the client entirely and you'd be left with at least a client that's far less hackish than it is now and it would probably improve network security at the same time.

If all we're talking about is just somebody's personal project, then that should have been made explicit from the get-go. It was presented as a draft for the community that the community should presumably care about.

So if this is just your personal thing, I'll stop commenting on it. If it's something for the community, I'll continue commenting on it, but in this case, it should not be viewed as a pet project. Either way I'd like to know what the deal is so that time is not wasted and communication is as expedient as possible.

I think it was made clear from the get-go that this was not an accepted IMC3 protocol. It's clearly marked as my own protocol that I'm submitting for consideration–With whatever changes someone wants to make if they do adopt it.


There's the first two lines of the post.

I see little reason why I should consider this a "community project" with no expectation it will even be used. Especially with me doing all the footwork. I'm doing my best to listen to ideas within the constraints of what I'm designing. Beyond that, I don't really know what you're looking for. But it probably isn't this.

I didn't mean that as a hostile remark. There is obviously a difference of expectations here. I thought we were talking about a community project, a draft meant for community consumption. You seem to think you're talking about your personal project. (So I'm not sure why you're surprised about doing all the footwork, especially considering that extremely few people knew about this until just now. And now that others are getting involved, you're telling them to back off because it's your personal project.) But, now you have made clear what your expectations and goals are here. I don't really see any further utility in commenting on this protocol unless and until it goes up for community consideration; if it's just your boat, you can float it however you see fit.

Ok, Now that Everyone's had time to calm down, I'm going to start this again.. Hopefully not with the same effect.

YAIMC is Runter's project. He's been doing all the work on it. I liked what I saw and decided it was worth considering as a viable replacement for IMC2.

That said, It was never just accepted as a replacement. Which is why I asked him to post about it. I never expected it to be met with so much hostility. Even with the bullshit that flew around in this thread, I still think this is a viable candidate for replacing IMC2. But no, it has yet to be accepted as an definite replacement for the existing protocol. The protocol is up for the consideration of the community. But Runter is free to do with it as he pleases until such a time as it does get accepted as the actual IMC3 Protocol.

If there are things people don't like about this protocol, I want to know. If there's something you want to see in a new protocol I want to know. Moving on, to address things people mentioned already.


I don't really care how this is done, in a new protocol, as long as the ability to request a who listing is possible.


I don't really see the point in this. If there is, I'm willing to listen.


This would be up to whoever ends up writing the accepted IMC3 protocol. I'd be fine with the delimiter just being a character not easily input on a keyboard.


Agreed.


No. The reason IMC2 Server Admins are the only ones capable of making channels is because if everyone is able to make channels whenever they want, the network is quickly filled with hundreds of channels that no one ever uses. Besides, Davion and I are generally pretty open to channel suggestions.


This proposed Spec supports this already. Will the MudBytes network allow it? Doubtful. I've yet to be shown a valid reason for needing this.


This I can agree with. And can certainly see many uses for it.



I'm not stopping anyone from I3 from contributing. This protocol draft is being developed independent of any existing MUD Codebase. And should it be accepted, Clients for various languages would be ready for release before the protocol was formally adopted. I'm not trying to merge the networks either. There's a reason I'm not on I3, and it's a reason I don't have to deal with on IMC. Nor is it a reason, I'll give to anyone, because it's no ones business but my own.


The IMC2 Protocol, Servers, and existing publicly available clients are too bulky and hard to work with for what the protocol is. Whether they work or not isn't the issue. The issue is that it takes almost 45 minutes to install an already written client. And a helluva lot longer to write one yourself. Whatever protocol is accepted as the new IMC3 protocol, will have to address these issues, and be installable in a lot less time. The idea is to get people to join the network. And if it takes at minimum 45 minutes to install the client. That doesn't really scream "implement me!" to me. If this protocol can reduce that time from 45 minutes to 5 minutes I'd be ecstatic. However, I'd be happy with a drop to 15 mins.

I'm not a fan of the "It's not Broke, Don't Fix it" policy. I've had plans to work on reworking the existing protocol for a while, I've just never had the time. Which is why when Runter came to me about doing it, I was all for it. And then he told me about some of the things he wanted to do in his implementation, and I was almost immediately sold. But IMC2 is not my protocol. It's not any one person's protocol. It's a Community protocol, and as such, it isn't my choice as to whether the YAIMC spec gets made the accepted replacement or not. It is however mine and Davion's choice on what the MudBytes Network will and won't support.

The spec needs cleaned up. And if we can clean it up and make it better in the process, I'm all for it.

Only one thought: distributed network.

Elaboration please?