New protocols: Introducing ESE.

Submitted by Cheetah on Sun, 2011-08-14 16:07

I promised in my last few posts I wouldn't want to discuss the actual representation of the protocol. I guess I lied. An example I presented today was met with enthusiasm from various parties, including at least one of the poor sods who would have to implement it. Thus I present: ESE (Extremely Simplified Enamel)

ESE is a very light-weight markup language that is relatively easy to parse and for most part butts out of your way. Here's an example:

This word is {color #ff0000|red}. You can go {exit|west} from here. Here is a word wrapped in curly braces: {oc}word{cc}.

This would likely result in the following text:

This word is red. You can go west from here. Here is a word wrapped in curly braces: {word}.

The word 'red' would ideally be in a red font, and the word 'west' might be marked up to denote that it's clickable, and on click would probably execute 'go west' in that case.

As you may see, ESE 'tags' are enclosed in curly braces. They have a tag name, an optional payload and optional contents.

The tag name says what the tag is for, what it's doing. This could be used purely to signal metadata, and new tag names can be made up on the spot. A client plugin or configuration may attach special meaning to a tag, and the MUSH may suggest actions for clicking on specific tags. An unknown tag is parsed but given no special meaning.

The tag payload contains additional information. For example, the color the contents should preferably be rendered in or the dbref or short form of an exit.

The tag contents are the actual text being marked up. For an unknown or unhandled tag, the visual representation of a tag would be its contents. For example, {image|http://example.com/example.jpg} would simply be represented as http://example.com/example.jpg. If you wanted to be fancy you could add support for the tag and make it a link (but still display the original text). If you wanted to be especially fancy you could replace the text with an inline image.

There are only three tags absolutely mandatory to parse ESE itself. And they're really simple. {oc} is an open curly. {cc} is a close curly. {bc} is a bar character. Parsing just these three correctly will yield the original text with no degradation. The choice to make these tags allows us to not bother with pesky entities like in HTML, XML and MXP, keeping the protocol as simple and uniform as possible.

To implement the actual protocol, there will be between one and several additional tags that are, if not absolutely mandatory, very strongly suggested to implement. These tags will be the ones supplying metadata about tags (meta-metadata?) to the client. Even then, the lowest level of support would be to simply discard the contents of those tags rather than displaying them, so that the end user isn't pelted with random garbage.

I will address some reasons why I chose to roll my own format rather than using already available ones such as MXP or XML in a future post. For now, suffice it to say that I have an example implementation in Python available that took only a few hours to bang together, much of that spent on documentation rather than code. On top of that, at least one client dev not only seems to like the format, but could implement it in relatively short time.