[MUD-Dev2] [DESIGN] AJAX Client/Servers?

[John Bertoglio]

> Morris Cox Thursday, February 15, 2007 8:30 AM
>> 
>> On 2/14/07, Phillip Lenhardt <philen at monkey.org> wrote:
>> Is anyone aware of or working on AJAX(ish) client/server
>> code for something mud-like?  I am specifically not
>> interested in emulating a telnet+ansi connection in a
>> browser.  I am interested in the details of making http
>> 1.1 keep-alive and chunking work (correctly? at all?)
>> to minimize the amount of socket creation/teardown, error
>> detection and recovery when sockets/connections close, etc.
>> Extra points if the server end code is in python.
> 
> I would also like to know. However, keep in mind that AJAX 
> refers to Javascript and XML. That means that MUDs and the 
> like would have to use or be compatible with the two. I know 
> that the OpenSource Metaverse Project (OSMP) at 
> http://www.metaverse-project.com/ uses XML. I don't > know how 
> well that might work for you. Seems to be C# on the backend.
>
 
Since 1999, my business has been converting conventional client-server
and character-based apps to the web. Projects where the client allowed
the web app to be "web-like" were generally much more successful than
those that insisted on modeling the exact behavior of the original apps.
When you have a direct connection, things like character by character
validation are trivial. You are already in direct communication with the
server and the round trips are optimized. In a web enviroment, this
approach is cumbersome. Yes, you can do model much client server
behavior with AJAX but the server round trips are not anywhere near as
efficient as with a direct connection. 

For example, command line auto completion is certainly possible with
AJAX. An alternative, providing a history dropdown, similar to a web
brower, would be much lighter weight and deliver much of the
functionality (you simply store each command in a local JavaScript array
and use DHTML techniques to prepend it to the history list). 

The key to a AJAX MUD implementation it to build the MUD as a web app,
not client-server. This means a stateless connection. There are low
volume, web-based technolgies out there that provide a persistant
connection. But, typically, they use the web to connnect the client
computer over port 80 to bypass firewalls. I do not know of any system
that supports large-scale, persistent connection using web/AJAX
technology. 

While my specific approach is not the only way to do this, using an
AJAX, browser-based front end to connect to connect to a database is a
powerful methodology. Because the database preseves system state, user
client interactions with the backend are usually brief and involve
moving small amounts of data. The reason to use AJAX is to avoid having
to constantly redraw pages, resending the user data that has not changed
(and will never change, at least in a give session). Going stateless
does create some user interface issues. Simple things in a client-server
environmet like real time trading and combat become a bit more tricky.
But standard housekeeping issues like inventory and crafting become much
easier to code. 

Bottom line, AJAX can make a web MUD feel much more like a true
client-server system, but no scaleable web technology can truly
replicate a dedicated client and real-time connection. Playing on a
web-based MUD will have a different feel. I think it will be fun but it
will be a more relaxed. I believe scalability along with the ability to
add tons of content in realtime will balance the modest limitations
imposed on the designer.