OpenRPG

I don't have much experience with the networking / messaging stuff but here's what I have dug out of the code: I'm using a plugin message as an example, specifically the blank plugin's demo message system "xxblank".

I think something similar happened with a bunch of the other messages (including the chat and map stuff which is embedded in <msg> element). I suppose the concept behind the new-style messages is that they are proper XML and can be thrown into an XML parser without breaking. Means (in theory) less messing about with string manipulation that essentially is all handled by any XML library the new way. However the big problem of course is backwards compatibility, since you just changed how messages are sent and received. For the plugin message the change over appears to be between 1.8.0 and whatever we're working on now (1.8.1? 1.9.0?) as of April 11th 2010. To try and build in some backwards compatibility the new server has some fudging it can do to accept old style messages, and the new style client has some fudging it can do to accept messages from old style servers. It is not perfect and here's the list of how it breaks down as far as I can see:

The format that the recevieng client expects (in this example "<xxblank>blah balh balh</xxbkank>") is unchanged throughout so that if the sending client matches the server all is well.  That accounts for four cases.  Fudging accounts for another three but there's no way (that I can figure out) to get a new client to somehow fudge the out-going message so that an old Server and Client can handle it.  So in that case someone has to update their client or go back to the version everyone else has.  Or find a different (new) server.

A snapshot of registered servers today, suggests about half keep up with the most recent server code but many of the most popular including Veav I stick with old -- in some cases REAL old code (and servers older than 1.7.1 seemed incompatible even with "old" clients as far as plugin messaging goes anyway, making "old" more or less 1.7.1 through 1.8.0).  Several servers, including the very popular Veav I send text (actually HTML) without a <chat> element.

Let's have a closer look at the fudge code. The server side fudge is contain in two separate functions, parse_incoming_dom(string) and plugin_message_handler(xml, string).  The first passes to the second (more or less) but for some reason unknown to man or beast in both new and old versions it extracts two copies of the incomming mesage and passes it on in both XML and raw string format.  Why?  At any rate in-line with the XML is king view the new code basically ignores (yet retains) the raw string after the XML is parsed.

In plugin_message_handler() the server required fields (from, to, group) are extracted from the XML. In the old system the message that is passed along to the receiving client is extracted from the string (by searching for the first ">" and assuming that is the end of the <plugin> header) and the new system ignores the string parameter and extracts the message from the XML (ie the child node).  The fudge in the new system is this: try to parse the incoming string as XML, and if that fails assume it's an old message from an old client and fiddle about to get the XML the way it ought to be.

If the sending client is new and the server old, the server manages to figure out the from, to, group fields just fine but its extraction of the message goes wrong and it sends the end node string "</plugin>" on the end of the genuine message.  A piece of fudge code on the new receiving client (it is found in a function called "client_parse()") then removes this string once it is determined the raw string message is bad XML.

So much for the plugin messages. How does the change effect more common chat and map messages?  Well for one thing there are two kinds of message to consider, the ordinary kind which are initiated by a client as happens with plugin messages, and the kind initiated by the server (basically the server welcome message and map / welcome banner).  For another some of the really old chat messages didn't even use a <chat> tag inside the <msg> tag but just placed HTML or even text directly after the <msg> tag.

The parse_incoming_dom() function handles all messages including <msg>'s chat, map and tree messages and the differences between old and new systems are the same as above.  Instead of going to plugin_message_handler() it goes to incoming_msg_handler().  The main difference here is that whereas the old plugin system passes on only the "msg" part of the raw text (the remainder after the <plugin .. /> head is removed) the <msg> handler just passes on the entire raw text unchanged.  This actually works out pretty well as it means a new client can talk to another new client through an old server as the old server changes nothing of the raw text.  There's one exception to that; when a new map is loaded it is stored minus the header.  That fails for an old server sent a new style map message (because the </msg> tag at the end is retained).  The upshot is that if you have new style clients on an old server then if you arrive to the room late you will get no map, but if the same map is saved and re-loaded by someone you'll get it fine.  Other than that the following table probably (yet to be tested) holds,

I think the new servers could detect for an old-style client and fudge the messages accordingly. Note that this means that a 1.8.1 (or 1.9.0?) client sending chat via a 1.8.0 server to a 1.8.0 client would fail.  In fact in testing the 1.8.0 client does better than other old system clients and delivers the message in a slightly mangled format (eg the font tag is visible as text in the chat window -- because the HTML is still escaped). <font ... >   </font> on every line pretty much.  This is because 1.8.0 has code to catch the exception when bad XML is sent to a client, and it then sends the raw text through to chat (without translating the &gt; / &lt; entities).

Lastly my predictions for server initiated msg messages,

Note: I know the server gets told the client's version but so far as I know not vice versa.  Still it seems like this could be changed so that new style clients could be smart enough to send old style messages and fudge the receipt of old style messages when they know that they are talking to an old style server.

And now how do the other miscellaneous messages (player, group, role, sound, ping, password) work with the old / new interactions?