New protocols: Additional musings

Submitted by Cheetah on Sat, 2011-08-13 19:08

Let me briefly cover two additional topics on the matter. One's about how to proceed once some ideas have trickled in. One's on, more or less, what the protocol would do as I envision it (but not yet HOW). I strongly suggest not reading this post until after you've made your suggestion on the previous one, if you're planning to do that.

The process of defining the protocol would happen roughly as follows:

  1. Gather all basic ideas on what functionality the protocol should provide.
  2. Discuss with codebase and client devs which features would be feasible. Which could be, with the possibility to degrade gracefully. During all future steps, keep a line of feedback with devs.
  3. Design how the protocol should achieve this in an abstract sense. (More on this below.)
  4. Design how the protocol should convey this information in a specific sense. (Mentioning words like 'XML' before this step would just be wildly premature.)
  5. Actually work to implement the protocol with at least one client and server.
  6. Hopefully become popular enough to spread.

Now.. Let's take a few points from step 1 and I'll give you my ideas so far for step 3. Again, you'll note that I'm not making any suggestions on how to represent things specifically. This is neither the hard part, nor is it interesting if step 3 can't be tackled adequately. (Much as reasoning about what shape a car should be for optimal performance is a bit premature if you're still working on inventing the engine.)

Some of the suggested or already existing uses of a protocol would be, in random order: Supplying metadata. Creating clickable links to send commands. Creating clickable links to pass to a browser. Creating links to images. (Which the client could interpret as clickables, or display inline.)

The idea, then, is to tag text not based on what you'd like to do with it, but by what what it means. (Note that I say 'tag', and if you really want you could think of it as an XML tag or something, but keep in mind that at this point we're still far more abstract than that.) For example, we might want a 'player' tag that says a bit of text represents a player name. And perhaps a bit of additional data that keeps track of the player's dbref. An 'exit' tag would be pretty similar, except representing an exit name, typically in the current room.

So, too, we could add a 'link' tag for web links, or an 'image' tag to represent a link specifically to an image.

This, then, would cover metadata, web links and images. How about commands? Let's add another system to the protocol, working very vaguely like a stylesheet. The MUSH would send the client a set of instructions, suggestions even, on what commands to run when clicked. For example, an exit tag should present 'go exit', a player tag should present '+finger player', and so on. At this point it would be safe to give mortals the 'exit' tag for use, right?

Well, one final snag: Now they can tag a bit of text like set(#7,WIZARD) as an exit, which would break our nice security model. To prevent this, I'd propose a directive to the client that says which characters to escape, and how. Typically, a MUSH would tell to escape ()[]{}\ with the \ character. At this point the client would never send those characters unescaped, and so softcode never evals.

Of course, sometimes it's plain useful to have the escaping not occur, and sometimes it's even safe. For example, the help command never evaluates, so not only is it safe to keep from escaping help topics, in cases like 'help %N' it would actively break things. Here we'd probably want to mark the 'help' tag as not requiring escaping. In addition, we can safely let mortals use this help tag.

It would make sense to supply a default set of tags, associated commands, and permissions for using them, and of course MUSH admin should be able to add, modify and remove tags and their permissions to taste. As long as individual tag permissions are handled with caution, it would allow mortals to use clickable tags with no additional permissions in ways that are impossible for security reasons with Pueblo. In addition, it could allow users to redefine what they want to happen when they click on specific entities. With a set of 'alternatives' you could even build context menus (say, +finger, +info and +time on player tags to allow a right click to invoke any of those).

If a client solely wants to use the metadata, not the clickability, it can. If a client wants to interpret images as inline, it can. The client can make any amount of assumptions it wants about the metatada, preferably by means of a set of standard tags like player, image, link, exit, etc. The client should (by default) make no assumptions about on-click actions and the like. Those are handled by the directives from the MUSH itself that say how to handle click actions. Of course, a user could then override the defaults to suit their needs if the client has that functionality.

I've about rambled on long enough now. I'm open for questions and comments. If this inspires you to work on this sort of thing yourself, I'm quite willing to let you and offer advice. If not, maybe I'll give this a shot myself at some point.