[MUD-Dev] mud client development systems

[Sunny Gulati]

Wow.  You folks are all amazing.   I'm getting more feedback than I have
bandwidth to investigate thoroughly :)   

Many thanks to Scatter for his/her pointer towards MudOS's ability to do
a secondary raw binary port built in to the mudlib.  That's #1 on my
list to check out.  And I'm going to take a peek at Chris Gray's socket
code.. that's #2. 

Going to let my mind wander some more... 

I was talking to a friend (I don't remember who) (in real life) (I think
it was my boss, AlanS at E-Markets.com), and he said: 

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

I *think* I know what CORBA is about, but its still fuzzy in my head. 
Seen too many vague marketing things on it, and too many C-library
implementations of it that already assume you know what its about.   I'm
doing a search on CORBA on the archives for this mailing list, see what
I can find.. 

oh my. the CORBA search returned a TON of stuff!  I'll go read it before
I ask more. 

-*-  

More dreamy stuff: 

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? 
I mean, if Steve likes Perl, he can write a client in perl, and the
mudclient in question can still use it, even if its written in... uhhh..
picking shocking language.. uh..  COBOL!   :) 

-> 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? 

Three ideas:  
  a) redirecting stdin/stdout/stderr - ie, i start the program in a
"subprocess", and I control its stdin, and I receive its stdout and
stderr.   I know Java + Perl both do this, and I'm sure getting C to do
it wouldn't be too hard, just gotta find the right examples :) 
  b) named pipes (how portable are they? does Win95 have them? )
  c) some sort of socket IPC stuff (how much cross-language support is
there?  how about on Win95?)

-> How does that affect my idea of "addressing" between clients and
servers?   Here's a harebrained idea I got during my drive back: 

On the mud, the server, having established we're dealing with a neato
client, wants to pop up a window on the server for chat messages. 

It calls a function to open a client-side-object of
type("instance/window/chat"), and passes a second function to call
whenever that happens (or dies). 

the mud sends this connection request as a method call to the
client-side kernel object. 

the client-side kernel object (written in Perl, for this example) looks
up its internal registry, to see who all can handle
"instance/window/chat" objects.   It finds that the Java object handler
says it can handle it.. so it passes the request on to the Java object
handler (which is tied through stdin/stdout or a named pipe or
something).  

The Java handler looks at its own configuration, finds the java object
it needs to new(), does that, returns the identifying info back to the
main client-side-kernel object, which sends that back to the mud.  
Which informs whoever that the client came up, and gives them their own
mud-side chat object to talk to. 

Benefit: 

-> you can write a client in any language, as long as there's a
switchboard (ORB?) object for your language. 

-> the distinction between protocol and client object is very distinct. 
Each client object registers the ability to handle particular
protocols.   Requests for services are along the lines of protocols. 

-> Instanceable objects vs Static, one-copy-only objects.  Note that I
said: 

  instance/window/chat 

meaning that this is an object that you create instances of (multiple
copies), it creates a window, and its a chat object. 

Other types could be url-handlers (static/url/http, static/url/lib)
which provide the user kernel methods of retrieving data.  These are not
"tieable" objects. 

Hmm.. rephrase this:  
  -> There are tied objects between client-side and mud-side
  -> There are objects local to the client side
  -> There are objects local to the server side (can't think of any
yet.. maybe an auth server?)
and 
  -> There are objects which there's only one copy of (like local
library looker-uppers)
  -> There are objects which need to be cloned/instanced

That's two dimensions.  I wonder if there are any others.

Drawback: 

uhh.. lots of client side objects running around killing the user's
CPU.   # of filehandles limits. 

gotta install client objects into your system if you want the additional
functionality.  

lots of chaos!

Note that I seem to be thinking about using stdin/stdout "wrapping" of
one process to another process to cross language boundaries.  I guess
that this is pretty expensive.  It would seem that languages that are
dynamic (Perl, Java) regarding compiling code on the fly and creating
new objects would be able to keep these sorts of expensive boundary
jumps to a minimum. 

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.   Like: 

      .link.   could be the telnet link (okay okay socket connection
between client and mud)
               left side is client, right side is server
      switcher.link  is the main switcher object.  Its written in perl,
for example
      chat.switcher.link  is the chat thingy written in perl (lives
directly off the switcher)
      5.chat.switcher.link  is the particular instance that we're
talking to. 
      java.switcher.link is the java handler
      198.java.chat.switcher.link is the java instance of a chat
handler. 

Wow, that's way too long to be useful.  Maybe some sort of unique number
could be arbitrated? (ugh).  Then again, it doesn't need to be human
readable - could just have: 

       198.3.45.1.0 

and each handler internally knows how to dereference one more number.  

So a message from/to on the server could look like:     
     from: 43  to: 0.68.34
0 references the link between mud and client, so that gets dereferenced
and sent over as: 
     from: 43  to: 68.34   (over the link) 
On the other side of the link, the object there happens to call the link
0 as well:
     from: 0.43 to 68.34
It looks up 68, and finds the java handler object.  So it sends the
message down the pipeline to the java handler.  While in the pipe, the
message looks like: 
     from: 0.43 to 34
The java handler grabs this, and dereferences object 34 to be the chat
window.  Its linkage upstreams is 0.   It sends it directly to the chat
object (since we're talking the same language and all), and there the
message becomes: 
     from  0.0.43 to [me]

Conceivably, one could have one client talk directly to another client
through the mud.  (just like that MCP client program did with its draw
stuff).   

-*-

I seem to have stabilized around the following kind of messaging
options: 

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

For more details, I've posted the various braindumps i've done at: 
  <URL:http://www.radiks.net/~sunnywiz/epcs>

That's not including the ruminations above. 

Sunny