Adobe AIR

[York]

Has anyone considered a default website that is used for browsing while the actual game-client is launched from AIR? (through a badge-installer if the client doesn't already have it installed)

Using Adobe AIR would standardize the use of web technologies such as javascript, css, and AJAX. More importantly XHR would be functional for all clients. Time-critical updates could be done through sockets, and data with higher priority could be cached client-side.

[krem]

I think the reason why many people are chasing the holy grail of Browser-only MUDs is because they don't want a client to have to download ANYTHING.

Now, that isn't to say there couldn't be a standardize JavaScript based library for MUDs, like gameQuery (a jQuery extension).

[York]

Personally I choose to use tools and platforms that
1) run on multiple major platforms (Linux, mac, windows)
2) have a high installation rate
3) come with most of the necessary components built it.

Having worked with C, and to an extent C++, I've long grown tired of wrestling with compilers and linkers. With the low-end languages a developer has two options on a project, either struggle with integrating libraries from multiple different authors or roll your own solution--I've done enough of the later to understand the benefits of the former. As they say, never reinvent the wheel...well, that is, unless you start-out looking to make some sort of improvement.

Erlang, and Adobe Air, as well as C to some degree, all are highly cross-platform and come with many of the tools and necessary functionality built-in.

Yeah Adobe AIR requires an installation but on the plus side you never have to develop for IE again. That and from what I understand Adobe AIR has over one hundred million installs. Seeing as it is already based on web-kit, the transition from AIR client to browser client will be much easier because *how* the client is supposed to function given a particular set of defaults will be standardized. From there it will be much easier to adapt existing code for the individual quarks of the various browsers out in the wild.

A cursory glance at various web statistics [inserts dubious research here] tells me two things...
1) People who prefer Muds are generally savvy to the modern software environment even if they choose not to utilize new software all the time.
2) The aforementioned people tend to avoid IE like the plague.

In the end the project I'm working on is about revitalizing the MUD industry, and moving standards forward, not by committee, but by setting an example that (hopefully) other companies will follow. With a richer, more media-friendly platform I'm hoping people that are familiar with clients such as ZMUD will take an interest in the project once it launches.

... that and I'm tired of having to search for alternate clients as old ones die out, and new ones spring up that don't support the operating systems I commonly use.

[mrfr0g]

I think the most ideal solution would be to have both the installer, and a built in client on the website. This would serve people who for some reason cannot, or don't want to install the client on their desktop. The feature set for both clients should be the same, so there isn't an advantage to one or the other.

[York]

I generally agree the base feature-set should be the same, however what about users or developers who want functionality that is not readily available on the majority of browsers? An example would be local storage (that isn't horribly limited or prone to deletion), or socket-access?