[MUD-Dev] Semi Graphical Muds

[Bruce]

Hi Christopher,

Thanks for your response!

Christopher Allen wrote:

> BTW, my problem with MCP is that it combines too many things into
> one layer, in particular, I'd like to see a separation between
> transport, services, and display.

Okay. I was perhaps a bit overboard in my enthusiasm for MCP. :) I
agree that it isn't the optimal choice if one were looking to start
from scratch with a new protocol, but:

  * It bootstraps well.
  * A lot of solid thinking has gone into it, which, if
    nothing else should be learned from and borrowed.
  * It is a good ground for doing experimentation in
    terms of application development.  It has existing
    client and server support and even some packages.
  * It is comparatively well specified.

Sure, it has problems:

  * Lack of similarity to other protocols.
  * Not likely to become any type of official standard.

> We had spec'ed a transport layer called Ellis, which was designed by
> Felix Crowes (author of DGD) and Par Winzell (of Skotos). It created
> a secured, authenticated, encrypted connection, onto which a host of
> private channels are automatically multiplexed in UDP and TCP. On
> top of it would be an action protocol, providing XML support, XML
> tag compression/aliasing, a naming scheme for channels and a
> subscription/registration service for client/server module pairs. On
> top of that would be a client specific scheme for displaying
> information into that particular client.

Have you looked at BXXP, XML-RPC, or SOAP?

BXXP (http://www.bxxp.org/) seems like it'd be the most interesting
from your description.

I think a world where I can write a quick program using XML-RPC and
query some bit of server state (assuming that I have the correct
security privileges, etc.) would be very interesting.  But the key to
getting there probably lies in some combination of:

  * Widely deployed and standardized protocol
  * Standardized and documented APIs on top of that protocol.
  * A good number of servers which support it.

But that's possibly a different land entirely from using that same
system for the usual communication with a client. (Allowing a
different type of bootstrap to occur, similar to the embedding of HTTP
and FTP servers into LPC systems, MOO, and Cold.)

But to me, this is a different proposition from trying to add some
semi-graphical type features to a system, where you'll (likely) have
disparate clients connecting.  (Although, I guess it isn't hard to
have a way for the client to signify what type of output they want and
to interact with the server in that form.  That just seems like more
work to me.)

> One of the things that slowed development of it is that at Skotos
> we've had to add another requirement based on problems that our
> customers have brought up -- firewall compatibility. Thus under TCP
> we need to redesign Ellis so that it can fake-out HTTP on port 80 to
> a state-aware firewall box. We have heard from a third-party that it
> has been done for a telnet style chat-client, so we should be able
> to as well.

Is this for people at home?  If it is for people at work, this may not
be a good idea (I thought the IETF discouraged this practice), and you
may not want to irritate firewall admins. :)

> We don't intend that Ellis (or whatever it is renamed when it
> becomes http friendly) to be proprietary, so we'll be glad to share
> it with anyone that wants to use it. I think that Felix wants to
> build it into the base DGD, so there will be a non-commercial
> version of it available.

That's a good thing to hear. :)

  - Bruce

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev