They don't necessarily have to be ASCII maps - some of the major mud clients support proper graphics.


Count yourself lucky - all I said was that I didn't know how feasible it was, and I still got disagreed with!


How effective is the caching? I play a browser game on my mobile phone, and it eats through my bandwidth quota like crazy. Sadly they have rules against using "modified" browsers, and they won't develop a mobile app.

At some point I still want to create a graphical Android client for my mud, with maps and avatars similar to my MUSHclient/Mudlet GUI. I did wondering about using HTML5 instead, but ideally the images should only be downloaded once (preferably all at the same time, so you can set everything up while using Wi-Fi). The same for sounds.

Of course we could also use that support; ideally people would be able to use anything from a telnet client to a mud client to a web browser client, thus not alienating any of our userbase.

I've set up an extremely basic socket server which I can telnet into and type commands and have them output back to me. Now I and my friend can start real coding; I'll probably open a new topic if we come across any other issues. One thing I don't have any idea how to do is how to output information in, say MCCP format. I assume there are libraries for it but those probably wouldn't work for PHP?

MCCP is "just" a matter of taking your output and passing it through zlib's stream compression before sending it off to the user. It's extremely easy for the server to utilize.

By the way, what Telnet library are you using (if any)? Telnet isn't just a raw TCP socket, and part of negotiating MCCP involves using Telnet option negotiation. I've seen enough broken Telnet implementations to be wary…

EDIT: A cursory search turns up stream_filter_append, which with the 'zlib.deflate' filter should work pretty well for MCCP.

I'm not using any telnet library yet, although it should be simple to impliment one. Can a scripting language like PHP actually take advantage of DLLs and other libraries? I've got little experience in this sort of thing don't know much at all about PHP; to be honest I'm working out the language just from taking code snippets and editing them.

let me rephrase:I'd rather run a web app of questionable origin on a common platform just because I clicked on a link that sent me to a forged webpage in order to exploit one of the many vulnerabilities of a brownser, than use a trusted appli I installed myself….
yeah right…

I too believe websites are so insecure that we only should download our content via installable binaries to be ran as machine code. Can't be too careful!

And we got to keep The Google out of our datas!

The only difference is that it's easier to accidentally download a malicious web-page. You argument might be used for not browsing the internet at all, but if we're debating the relative merits of web apps versus native apps it doesn't really apply. If you choose to use one, you're trusting it, whether it's a web app or a native app. And the browser has a smaller exploitable surface area because it's locked down.

I mean, there are annual events dedicated to finding exploits in the browser, and these bugs are often really difficult to find. Now, I'm not saying there are no exploits, but compare that to the sheer amount of access a native app has by default. You're trusting the app not to misuse its power, rather than trusting the platform to be difficult to exploit.

That is the problem ou do not choose to use a webapp, you just click on a link that could lead you to whatver it wants and not what you thought it was.
My application menu does not do that.
That is also why webapp are always more limited in what they can do, for this very security reason.


it shows that even sandboxed in a brownser, your computer can be pwned by clicking a single link. I would prefer the navigator stays what it should be: Showing data, not emulate a complete OS.

Why do you even need a browser? Use bash and grep.

You're conflating separate issues. In one case, you're claiming that you don't know where links go because it's someone elses software that you're using. In another, you're claiming you do know where the links go in your menu application. When in reality, if you wrote both apps you'd know exactly what they do. If you didn't write both applications, then you certainly would be more secure clicking on a link to a web app than downloading a binary and installing it. At least with a web browser it's sand boxed. With an installed application, it has the keys to the city. Not only do you not know what it's going to do, you may not know afterwards what it did. I feel like your argument is so absurd that I don't care to entertain it any longer. If you don't like browsing the web then don't, but it's quite interesting that you're using mudbytes.net. Which is indeed a webapp. Would you rather mudbytes have a binary you install so you can access their forums? And hope it's not doing anything malicious? That would be silly, right?

I'm just going to quote this here for truth.

hey don't rule out a maliciousBytes application coming to a desktop near you…

As a 6kb executable that requires admin privs.

sudo apt-get install maliciousBytes

I'm not a bandwagon rumor spreader :-p. My salary depends on my knowledge of browser performance, and I'm promising you that the current tech is quite a ways away from being anywhere close to as performant as Mush. Heck, the difference between mush and other clients is in itself pretty huge! By the by, 3D games are not very taxing natively. Its all the extra shaders and physics which really put the hurt on your system, and while I've seen some pretty impressive GL demos in canvas recently, people aren't playing Crysis in their browsers.

FWIW, Mozilla recently created a real-time syntax highlighter in canvas which was taxing enough in and of itself to require pretty slick algorithms to circumvent. The project was merged with the Ace editor which now uses the DOM instead of canvas for performance gains (ironically enough).

Oh, and when can we get a mobile friendly forum UI? Posting on my DROID is like pulling teeth…

It's clearly not the forum's fault as I post just fine with my iPhone :)

RIP Steve Jobs

re Deimos,
I made the comparison between C and high level languages because of exactly what you replied with. You are confusing less performant with not performant enough. So I don't know what your salary depends on; Don't care, but Appeal to Authority is a fail debate tactic. The fact of the matter is web browsers can handle running a mud client. You could run multiple mud clients in a web browser. Yes, canvas is inefficient. Yes, canvas isn't even widely supported in legacy. You're the only person talking about canvas here. Why would someone use canvas for this? So maybe you're not very authoritative on how one would even go about making a mud client in a browser. Ask Twisol if his upcoming client is using canvas. Ask him if even V8 isn't enough for him, and while you're at it, ask Twisol how heavy the super computer in his basement must be to possibly bring the technology of 1980 to todays web browsers.

@Runter: You seem to be taking this personally, and prefer to attack me/my "debate tactics"/etc. versus actually responding to me, so I won't carry this on any further than to point out that your one and only example is a far cry from replicating Mush, which was the original topic of this tangent. In fact, I posit that your example doesn't even implement zlib decompression, and likely not even remotely as elaborate a trigger system as Mush, let alone the slew of other performance-killing features that Mush has done very well at streamlining.

In short, I feel that you drastically underestimate the tech behind one of the best MUD clients made. You also seem to be misrepresenting the argument (forgive me, I forget the exact term for this debating fallacy); we aren't talking about simply "making a MUD client in the browser". But I know that you know that…

Also, re: the canvas thing, I mention it because a lot of the great features in Mush would all but require it. Unless you're up for a real challenge, anyhow. Of course Java and/or Flash are alternatives, since the technically run in the browser, but I thought we were talking native browser dev. Anyhow, I digress.