[MUD-Dev] Re: mud client development systems

[J C Lawrence]

On Sun, 13 Dec 1998 22:06:48 -0600 
Sunny Gulati<sunnywiz at radiks.net> wrote:

>   "Sounds like you're trying to implement CORBA on a mud".

Way back when we had one of the principals from GnuStep on the list, 
and he asserted much the same thing.  GnuStep might well be
something to check into.

> Talking to another friend Steve (wells at cedarnet.org), and he was
> interested in doing some Perl/GTK or Java client-side coding if I
> got my ideas along far enough.  This got me thinking, on the 2
> hour drive back from his place.. he wants to play, but its not the
> same place that I am looking at playing... I want to do Perl/Tk
> (just because)... and Matt Messier, another friend, would want to
> work in C++..

>   - i wonder if I can make my client side objects language
> independent?

Yes, what you need to do is to define and document and
pickle/unpickle process for your objects (see Python for a pretty
good example) and messaging/function-call semantics (how are
arguments presented etc) .  Then contributors working in foreign
languages need merely comply with your pickle and calls standards to
interoperate.

> Obviously, it would have to run in a seperate process.  Need to
> communicate back to the master client program (which has the
> connection back to the mud).  How should I do this?

Look into Muq and its runtime variable command processors (ala Unix
command shells).  

No, you can also use embedded interpreters.  While Perls doesn't
submit easily to mebedding, python embeds very elegantly and simply
(can you tell I'm a fan?), and Tcl/TK isn't *too* difficult as long
as you restrict your call set.  C++ or anything else that produces
linkable objects then merely depends on call/interface standards.

> Back to the quesiton of how would I identify stuff?  I was
> initially thinking of something like how routed and the internet
> do stuff.. then I thought the object identification could
> specifically describe the path to get to it.  

Have a look into the naming system used in CoolMUD (forget the name
right now).

> Message = send a message, expect no response. Query = send a
> message, expect response. Reply = reply to a query (references a
> message id#) Replyuery = reply to a query (references a message
> id#), expects a response

<nod> I don't see a real need for the third case tho.  It seems more
sequence of two #1's.

I use transaction frames.  I have a FRAME message type which starts
a transation, and then an ENDFRAME message type which ends it.
Frames can of course be nested.

Your first case (message with no respose) then derives to:

  A->B:  FRAME 
  A->B:  Message (data)
  A->N:  ENDFRAME

Case #2 derives to:

  A->B: FRAME
  A->B: Query (data)
  B->A: Answer (data)
  B->A: ENDFRAME

Actually there's a FRAME_ID specc'ed on each FRAME message.  A
complex transactions would then turn into:

  A->B: FRAME 1
  A->B: Query (data)
  B->A: FRAME 2
  B->A: Query (data)
  A->B: Answer (data)
  A->B: ENDFRAME 2
  B->A: Answer (data)
  B->A: ENDFRAME 1

The reason for using the frames as versus merely tracking the state
machine via the message types and tags is that (and this is a broken
aspoect of my design in some ways) certain queries will generate
multiple responses and I need the query frame not to state
transition before all the answers are in.  

I tried to make it a bit cleaner by making the frame typically part
of the header fields for the messages so the minimum number of
messages get passed, but they can be first class messages if needed
(happens in some cases for multi-message replied where tracking gets
too difficult).

--
J C Lawrence                              Internet: claw at kanga.nu
(Contractor)                             Internet: coder at kanga.nu
---------(*)                    Internet: claw at under.engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...