WhelkMud - mxp extensions

These are the proposed changes to the Mxp standard to support to some extra things to make the discworld user experience better.

Events

<!entity channelist "cre|newbie|code|am|ram|cwc">
<!event Channel player="{player}" name="{channellist}">

<event Channel player="pinkfish" name="cre">data</event>

So there are two extra tags defined, one defines events which can be sent down from the mud to the client and what parameters they take. The {player} means that it uses a player name in there, the {channellist} tells the system to get the list of possible values from the channellist entity. The entity is defined using the standard mxp entity definition code.

The use of this sort of definition will allow the client to do much better matching of incoming information, so you can say on the client: send all tell events from pinkfish to highly important window.

The events would all need to be defined when the player enters the game, and updated whenever these details change.

As part of this, extending entities to be updateable will be needed to reduce network traffic.

<!entity player update="+pinkfish">
<!entity player update="-pinkfish">

Server querying

So the client can send a query down to the service and have the service respond with a useful piece of information about whatever is queried.

First you send down a !define tag to define the data that will be send with the types of data. The define should correspond to a value used in the events, since it is the events that will be used for this extra details. So if the event has {player} as one of it's thingies. Then we define the "player" type below to contain a bunch of details about guild affiliation etc.

<!define player guild="Warriors|Wizards|Frog" club="club list" family="family name">

So when the client sends a request, it is of the form The type is defined above and the id is the element of that type to retrieve.

<query request player playername>

<query reply player playername guild="guild" ...>

Tables/Columns

Allow the use of tables inside the system. Use a similar system to html, but do not allow as much control. Only allow variation in the rows/colums. So you can have x rows in your table, or y rows, but not a combination of both.

Should we only allow columns and let this be a column mode? By using tables we allow the system to be more flexible in the future. It is possible that just by using the richtextbox inside .net I will be able to get all of the functionality of a html table anyway.

<table>
   <tr>
      <td width="15c">Text</td>
      <td>More text</td>
   </tr>
</table>

Pageing

If a very long piece of text is sent from the mud down to the client, the client should do the paging of the information, not the service. We do this by wrapping the text to be paged with a <page>text</page>. If the client sees this it will display one page at a time and let you press 'tab' to continue to display the file. The client input window should break in two at this point so the top section shows you the file being paged and the bottom shows you the current output.

<page>text to page</page>

Fonts

Allow a special colour 'default' to be used for foreground and background colours. This will set the colour back to the default. There is also a type called 'fixed' and 'proportional'. These will make the system choose the users defined fixed and proportional fonts for the output. As much as possible it should use the user fonts for printing and not ones decided by the server itself.

<color fore=default back=default>
<font happyfontname color=default back=default>

Forms

Allow the mud to send down forms to the client for it to fill out and send back.

<form url="http://whatever" id=234 action=send expire="mail" to=pinkfish>

Where the form tag is of the form, url=<url> action=<send|data> and the rest of the parameters set variables which will be filled in on the downloaded form. They should correspond to the names of elements inside the html form.

The action controls how the form deals with the data that is to be sent back. If the action is one of the standard html ones eg: post, then it will do the normal html processing. If the action is 'send' then it will send the return tag from the form to the mud. If the action is 'data' then it will turn the result of the form into a <data> tag and send that up to the mud.

The id sets how the system links a input form with the output, it uses a combination of the return url and the id. This allows the system to handle multiple of the same form being opened on the client side and still correctly figure out the data responses.

<data url="http://whatever" id=234 to=pinkfish message=data subject="happy bananas">

This tag should be effectively processed 'out of band', so the users main input window should be at the normal mud prompt while a 'data' form is being processed. A 'send' form should be done as a modal dialog box.

Editing files/things on the client

Instead of pushing down a html form to edit things, it would be useful sometimes for the system to enable the editing of files using the persons favourite text editor on the client side. Especially for creators, so they can click on a file, download it to their system and then edit it, upload the changes. Perhaps allow for 'diffing/patching' to reduce the network bandwidth.

<edit url="url to get the file from" id=123>
<edit data="data" id=123>

Mxp Extensions