14 Sep, 2011, KaVir wrote in the 21st comment:
Votes: 0
quixadhal said:
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.
14 Sep, 2011, David Haley wrote in the 22nd comment:
Votes: 0
KaVir said:
quixadhal said:
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…
14 Sep, 2011, Baiou wrote in the 23rd comment:
Votes: 0
Oh UDP
14 Sep, 2011, Runter wrote in the 24th comment:
Votes: 0
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 :)
15 Sep, 2011, Tyche wrote in the 26th comment:
Votes: 0
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.
15 Sep, 2011, Runter wrote in the 27th comment:
Votes: 0
Capable of what?
15 Sep, 2011, Tyche wrote in the 28th comment:
Votes: 0
Runter said:
Capable of what?

quixadhal said:
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?

{"look" : "apple"}
{"huh?" : {"room" : ["orange"]}}
15 Sep, 2011, Runter wrote in the 29th comment:
Votes: 0
Tyche said:
Runter said:
Capable of what?

quixadhal said:
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?

{"look" : "apple"}
{"huh?" : {"room" : ["orange"]}}


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?
15 Sep, 2011, Twisol wrote in the 30th comment:
Votes: 0
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).
15 Sep, 2011, Runter wrote in the 31st comment:
Votes: 0
Twisol said:
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:
16 Sep, 2011, Baiou wrote in the 33rd comment:
Votes: 0
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?
16 Sep, 2011, Tyche wrote in the 34th comment:
Votes: 0
Runter said:
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.

Runter said:
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.


I'm not so sure we all know that spamming structured data in JSON isn't a game communication protocol.

Runter said:
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?

I'm using neither.
16 Sep, 2011, Runter wrote in the 35th comment:
Votes: 0
I can just assume you're trolling, then.
16 Sep, 2011, Tyche wrote in the 36th comment:
Votes: 0
Runter said:
I can just assume you're trolling, then.

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.
16 Sep, 2011, KaVir wrote in the 37th comment:
Votes: 0
Tyche said:
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 (!).

Tyche said:
I'm using neither.

What are you using?
16 Sep, 2011, Scandum wrote in the 38th comment:
Votes: 0
KaVir said:
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.
17 Sep, 2011, Tyche wrote in the 39th comment:
Votes: 0
KaVir said:
Tyche said:
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.

KaVir said:
What are you using?


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.
18 Sep, 2011, Baiou wrote in the 40th comment:
Votes: 0
How far are you along? @tyche
20.0/128