Being a web developer, and one that is very familiar with the newest canvas API and JS, I'd have to say that, while it would probably be possible, it would definitely not be feasible or practical to recreate something like MushClient within the browser.

The mud uses a flash client, not raw brownser. And you could still use the JAVA plugin then the point is moot, you can definitely recreate whatever program you want in an applet.

I disagree 100%. Whether or not it would take a long time to refine all the features mushclient has is another thing. Mushclient was developed for a long time, but the fact of the matter is the platform isn't the problem at all. I'd suggest you can make something *nicer* than mushclient.

People here like to argue a lot, don't they ;0

Currently any web browser client would be fairly simple, until we've got both telnet and web browser and basic gamefunctionality set up. If the game became more popular, sure, we could make a flash or java web client, but right now we just want to get the basics sorted out.

EDIT
That michaelcamden.me and http://www.devshed.com/c/a/PHP/Socket-Pr... are both extremely useful and relevant to what I needed to know, thanks very much!

I guess, but I think that's the normal course of good discussion about philosophical and technical issues in general. If we all had agreement on everything, this forum wouldn't be nearly as interesting. (or useful)

And generally the disagreements aren't too bitter.

Yes, QFT. The issue in recreating MUSHclient isn't the platform – it's recreating the many, many years of work that went into it.

Better go tell all those HTML5 developers at places like Google and Microsoft, for that matter, that they're fools for using the web as a platform for rich client application development. :smile:


This is a case where you won't divide and conquer; you're more likely to divide and flounder. Figure out what gives your web client an edge, and focus on it. If you can't figure that out, focus on standard telnet clients.

I would just tell them they are assholes…that 'their rich client application' are not that rich, and only have one goal in mind, tie me to their service as my datas are only really usable online on THEIR servers.

^^ lawlz, What are you talking about?

Not sure where that mini-rant came from since we were discussing platform capability, not data or services, but FWIW read this.

Web client means instant access upon finding the site, no telnet client installation needed. Also would have buttons for directions, separate chat window where any chat would be sent to rather than the main text window, and probably would have forum integration as well. But anyway, getting the basic codebase done is more important than thinking about a web client's extra features.

Unless, of course, those web client's extra features are going to be part of the basic codebase. Still, if your goal with a web client is to basically have just telnet in a box, then that's fine. I just tend to think that's a little shortsighted in today's world and misses the point of where things are going – it feels like putting together a beautiful, wonderful train… but a steam engine train.

Eventually we would probably do a lot more with the web client, assuming we finish the first release ;0 however, we also want to have the telnet version not limited in any way, other than not having extra feature integration. So the web client might have a map too, and the telnet client would then also get some sort of ascii map. I don't want to alienate either group of users.

I said it would be possible, so I'm not really sure what you're disagreeing with; that I said it wouldn't be practical? You even grant that it would take forever to recreate it. :-p Not only that, but real-time ANSI/zlib implementation performance in a browser would be abysmal, even using V8, so I don't see it even being possible right now to recreate the same experience, even if it were feature-complete.

Before what I disagreed with is that your post says basically that being web tech is what makes it less feasible. So that's what I disagree with. I think it's actually more feasible in web tech than what mushclient is written in for someone who wants to start writing a new client.

Now what I disagree with is that you're saying that performance in a browser would be abysmal. This is nonsense. There's fully 3d rendered games being played in browsers right now. On this last point, it actually reminds me of people who say interpreted languages are just too slow and we *must* use C. It's just not true.

Data are meaningless without a way to use them to 99.9% of the user. so if the software is only available online.
Yes there are html5 software you can 'install'. It would be naive to think it will be the rule, as you are the product, not the client.
This whole html5 craze from the big sofware provider is to try to get back to the client server model, where you are the client, and they are the masters.
So you have to pay them a rent to use your data, be it in mindshare for a free service, or data mining, money or whatever.

Which services in general do you have a problem with? I don't have any problem with my gmail account, for example.

Frankly, it sounds like you're mad you can't pirate their software?

Err not at all, their softwares just sucks anyway, a brownser can not compete with a native program yet. I avoid to use them most of the time.
It is even funny how people complain about JAVA but are ready to use their brownser as an application.
The real problem is that they control the data. I dont like my post office to make a copy of all my mails as an example. Or even to be able to read through it. Or make it unavailable at their will. If you dont have a problem with your gmail account, great for you, I hope you make a local copy, and then there are better mail application than their webapp.

In what way can a browser not compete with a native program? I don't even understand what your point is because you're all over the place. Gmail's web interface is different from their service. I use OSX's mail application w/gmail service. There's a lot of reasons why web based services are more convenient and safe than rolling your own for every service you need. I guess I'd give you the same advice. If you don't like it, don't use it? What's wrong with a company making the optional available? How does that rise to the occasion of needing to use terminology describing them as some evil empire trying to enslave you with their free software?

One of the very problem with brownser is security. There are reasons you have sandboxes, limited access to hardware and most OS API.



Free always come with a price that ends up being greater to pay than before. There is no free as in beer. You do not have a choice to boycott Google as matter of fact. Everytime you but a product that has been advertised on Google, you pay Google.

I'm not sure what point you're trying to make. MUSHclient (and presumably Mudlet) is very insecure, largely because you can access file and OS APIs directly through Lua's standard libraries. Nothing prevents a script from wiping your files. In contrast, the browser is highly locked down, but new APIs are being worked on to provide access. WebGL, for example, lets you utilize the GPU directly.

I'd rather run a web app on a common platform (the browser) than use a native app of questionable origin, precisely because the latter has more access to my machine.