Ok, so… now what's the advantage of continuing to use TELNET while using GMCP/MMP/MSDP as opposed to an industry standard like JSON?
If you're using GMCP, then you're already sending JSON formatted data over telnet.
Yes, but ATCP2 is wrapped in a bunch of other overhead of having to deal with telnet subnegotiation etc.
This would be kind of like saying we should use UDP, and then proposing a protocol that sends UDP over TCP, and saying we're good because we're already sending UDP…
I think it's a fallacy to believe all things are equal just because they're possible in two separate technologies. It's similar to turing complete arguments about programming languages. Why should I use <insert superior technology> instead of <insert inferior technology>? How are you going to convince me of that when I can do everything you can do in the inferior technology? It may raise the entry level for new developers, it may be ugly, it may require more work in the long run… but how are you going to convince me when it's Turing Complete? Obviously, this argument has long been settled.
So to sum up the arguments on both sides over the years: Pro Telnet: It's good enough. Con Telnet: It's not good enough.
People already know where I stand. I wouldn't consider using telnet for a new project no matter how impassioned an argument someone married to it makes, and there's not a single mud client out there with features that I think are good enough to merit me building legacy support for it. I believe the mudding population is so low, while the internet using population continue to grow, that I don't care about legacy support or about attracting people who only want a traditional experience. I'm more interested in attracting players who've never played a mud (a huge population), and they don't have the same sensibilities about needing to use their favorite mud client to play.
15 Sep, 2011, JohnnyStarr wrote in the 25th comment:
Votes: 0
Personally, I think that technology holds very little relevance to what constitutes a "good" game. "Galaga" for example is one of my all time favorites; and it was written in some type of proprietary assembler. There are several C based MUDs in operation that have taken the golden-age mud concepts to a completely new level. The only change in technology might be they are using gcc 4.4 instead of cc 1.5 – or what have you.
Regardless of technology, good games should be well written; extensible, scalable. Some newer languages / platforms allow for a more structured coding discipline. These "technologies" assist the developer. But really don't affect game play.
I think that clients and protocols enhance the spirit of the MUD at hand. But I don't feel that they take MUDs beyond their intention: to fully immerse the player into a fantasy or illusion. It could be argued that nifty clients or even colour for that matter 'take away' from the interactive-book feel of old muds.
Every player has their own opinions. These are just a few of mine. With my studies I don't have time to program as much as I would like. Have fun :)
JSON just isn't capable. BSON is much closer. Screw JSON and the hobby horse it rode in on. And besides sending structured blobs of data around doesn't a game messaging protocol make.
Ok, so… now what's the advantage of continuing to use TELNET while using GMCP/MMP/MSDP as opposed to an industry standard like JSON?
Not to pick on HaikuMud, but I was checking out Haikumud and noticed that it's negotiating using HTTP. Then it's sending me reams of XML. What's the advantage of continuing to use HTTP as opposed to an industry standard JSON? Why don't you cut out this unnecessary overhead of HTTP and XML and just give us the JSON?
Ok, so… now what's the advantage of continuing to use TELNET while using GMCP/MMP/MSDP as opposed to an industry standard like JSON?
Not to pick on HaikuMud, but I was checking out Haikumud and noticed that it's negotiating using HTTP. Then it's sending me reams of XML. What's the advantage of continuing to use HTTP as opposed to an industry standard JSON? Why don't you cut out this unnecessary overhead of HTTP and XML and just give us the JSON?
I do use JSON both ways for all packets. There's places, specifically the initial login, where HTML is streamed in over the websocket, but other than that it's not the case. Well, I think even then it's using Json packets to do it. So maybe you just peeked at the login screen?
So I guess you're trying to make some weird point that JSON is a format and not a protocol, but we all know that.
But my question still stands. JSON isn't capable of what that BSON is?
Frankly, the biggest difference is that BSON has more datatypes. It's apparently also easier to traverse (i.e. string length comes before the string itself).
Frankly, the biggest difference is that BSON has more datatypes. It's apparently also easier to traverse (i.e. string length comes before the string itself).
Yeah, I can only assume he's talking about efficiency, but I don't know why that would matter since both JSON and BSON would be fine for most purposes.
15 Sep, 2011, David Haley wrote in the 32nd comment:
Votes: 0
Not sure if Tyche's argument should be taken terribly seriously, folks. :smile:
Off topic @David Haley I like your webpage. On topic, allow a brief proverb: A swordsman uses a sword and a serial killer uses whatever a serial killer uses. Aside from the arguement, what is being done with these "better" structures to further the games? Whether it's server or client side, just what?
I do use JSON both ways for all packets. There's places, specifically the initial login, where HTML is streamed in over the websocket, but other than that it's not the case. Well, I think even then it's using Json packets to do it. So maybe you just peeked at the login screen?
I peeked using a packet sniffer. Anyway it's not so different that you're negotiating client capabilities and transferring files with HTTP and others are negotiating client capabilities with Telnet.
But my question still stands. JSON isn't capable of what that BSON is?
Correct. See http://en.wikipedia.org/wiki/Comparison_... Of course that list doesn't even scratch the surface of useful formats. There's probably more data formats than muds.
BSON is faster. No data conversions needed. It supports binary data natively. Besides, all the smart cool kids are using stuff like BSON and ProtocolBuffers these days. So why are you luddites clinging to slow and outdated JSON format?
No, but it's not uncommon that I get cryptic comments like the above after my browser filters out certain members' posts. In other words, I have no clue where you got that idea.
I peeked using a packet sniffer. Anyway it's not so different that you're negotiating client capabilities and transferring files with HTTP and others are negotiating client capabilities with Telnet.
So what we're really comparing here is telnet vs HTTP.
Tyche said:
BSON is faster. No data conversions needed. It supports binary data natively. Besides, all the smart cool kids are using stuff like BSON and ProtocolBuffers these days. So why are you luddites clinging to slow and outdated JSON format?
BSON does look like a better choice than JSON for a modern mud, particularly if you're transferring graphics and sound. And of course it's "newer", which some people seem to view as the most important factor (!).
BSON does look like a better choice than JSON for a modern mud, particularly if you're transferring graphics and sound. And of course it's "newer", which some people seem to view as the most important factor (!).
I'd suggest using a separate transfer protocol for binary data, this because you'd want to send files in blocks of 500 bytes at a speed of about 1 KB/s, with support for partial downloads.
I peeked using a packet sniffer. Anyway it's not so different that you're negotiating client capabilities and transferring files with HTTP and others are negotiating client capabilities with Telnet.
So what we're really comparing here is telnet vs HTTP.
Well take this observation FWIW… Around the same time as DikuMud was released, HTTP was developed and the World Wide Web was born. Now after twenty years, we've finally got the latest and finest bleeding edge technology. So you get your Ruby Webrick server running including all the latest gems. You've written your HTML, CSS, Javascript, Coffescript, Abobescript. You fire up a browser and point to your server and start sending hundreds of packets back and forth negotiating its capabilities, installing the the latest Adobe Flash and Google Chrome plugins, install script shunts and workarounds for different browser versions. Now you're ready to go. You've leveraged millions of man hours work and have years of development by the brain trusts of Abode, Mozilla, Microsoft, Google and many other smaller concerns behind you. You got your many layers of frameworks all talking to together; and you hope all the right versions. You open that once forbidden connection, and wait for the server response. All that high technology churns… The server coughs up twelve cryptic bytes…
IAC DO TTYPE IAC DO SUPGA IAC WILL ECHO IAC DO MDSP
The Internet groans and your application dies with the overhead and futility of parsing these final bytes.
The point being that your mud and Runter's mud are sitting there at the same point with a TCP socket open. You've implemented a couple protocols to communicate with your different clients, and Runter has implemented a protocol to talk to his clients. His is not simply JSON, and yours isn't simply MDSP. Both have meaning independent of whatever data format you both chose. Capturing the meaning, the what, when, why, how, and sequence and is the real protocol.
I'm reinventing the wheel just like everyone else. It's a network stack that implements an event messaging protocol. You should be able to plug it in to just about any client or server and not care how it works. It runs over UDP/RUDP and implements message channels. You open channels to do file transfers, streaming, send complex objects or you could even open a channel to send "legacy" mud messages. I'm creating channels that send data in a home grown format that uses some of the same principles as BSON (and many many others use).. [data type][length][data bytes] But like I said above, the data format, isn't important. Defining a high level game messaging protocol and well done API is what I'm going for.
If you're using GMCP, then you're already sending JSON formatted data over telnet.