<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] mud client development systems --> <!--X-From-R13: Ehaal Uhyngv <fhaaljvmNenqvxf.arg> --> <!--X-Date: Sun, 13 Dec 1998 20:07:11 -0800 --> <!--X-Message-Id: 36748ED8.99E8CF8C#radiks,net --> <!--X-Content-Type: text/plain --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] mud client development systems</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:sunnywiz#radiks,net"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00961.html">Previous</a> | <a href="msg00963.html">Next</a> ] Thread: [ <a href="msg00908.html">Previous</a> | <a href="msg00977.html">Next</a> ] Index: [ <A HREF="author.html#00962">Author</A> | <A HREF="#00962">Date</A> | <A HREF="thread.html#00962">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] mud client development systems</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Subject</em>: [MUD-Dev] mud client development systems</LI> <LI><em>From</em>: Sunny Gulati <<A HREF="mailto:sunnywiz#radiks,net">sunnywiz#radiks,net</A>></LI> <LI><em>Date</em>: Sun, 13 Dec 1998 22:06:48 -0600</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> 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#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#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:<A HREF="http://www.radiks.net/~sunnywiz/epcs">http://www.radiks.net/~sunnywiz/epcs</A>> That's not including the ruminations above. Sunny </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <ul compact><li><strong>Follow-Ups</strong>: <ul> <li><strong><A NAME="00977" HREF="msg00977.html">[MUD-Dev] Re: mud client development systems</A></strong> <ul compact><li><em>From:</em> J C Lawrence <claw#under,engr.sgi.com></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00961.html">[MUD-Dev] Re: small dev-mud invite</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00963.html">[MUD-Dev] AFAP: As fast as possible, non linear...</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00908.html">[MUD-Dev] Re: mud client development systems</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00977.html">[MUD-Dev] Re: mud client development systems</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00962"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00962"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>[MUD-Dev] Re: Stack-Based NPC AI</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <ul compact> <LI><strong><A NAME="00926" HREF="msg00926.html">[MUD-Dev] Re: Stack-Based NPC AI</A></strong>, David Bennett <a href="mailto:ddt#discworld,imaginary.com">ddt#discworld,imaginary.com</a>, Mon 07 Dec 1998, 20:05 GMT </LI> </ul> </ul> <LI><strong><A NAME="00912" HREF="msg00912.html">[MUD-Dev] Re: Stack-Based NPC AI</A></strong>, Marc Hernandez <a href="mailto:marc#ias,jb.com">marc#ias,jb.com</a>, Mon 07 Dec 1998, 00:22 GMT </LI> </ul> </LI> <LI><strong><A NAME="00907" HREF="msg00907.html">[MUD-Dev] mud client development systems</A></strong>, Sunny Gulati <a href="mailto:sunnywiz#radiks,net">sunnywiz#radiks,net</a>, Sun 06 Dec 1998, 21:37 GMT <UL> <LI><strong><A NAME="00908" HREF="msg00908.html">[MUD-Dev] Re: mud client development systems</A></strong>, Caliban Tiresias Darklock <a href="mailto:caliban#darklock,com">caliban#darklock,com</a>, Sun 06 Dec 1998, 22:04 GMT </LI> </UL> <UL> <li><Possible follow-up(s)><br> <LI><strong><A NAME="00962" HREF="msg00962.html">[MUD-Dev] mud client development systems</A></strong>, Sunny Gulati <a href="mailto:sunnywiz#radiks,net">sunnywiz#radiks,net</a>, Mon 14 Dec 1998, 04:07 GMT <UL> <LI><strong><A NAME="00977" HREF="msg00977.html">[MUD-Dev] Re: mud client development systems</A></strong>, J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 17 Dec 1998, 04:47 GMT </LI> </UL> </LI> <LI><strong><A NAME="00971" HREF="msg00971.html">[MUD-Dev] mud client development systems</A></strong>, Jay Carlson <a href="mailto:nop#mitre,org">nop#mitre,org</a>, Tue 15 Dec 1998, 22:56 GMT </LI> </UL> </LI> <LI><strong><A NAME="00906" HREF="msg00906.html">[MUD-Dev] Introduction</A></strong>, Mik Clarke <a href="mailto:mikclrk#ibm,net">mikclrk#ibm,net</a>, Sun 06 Dec 1998, 20:26 GMT <UL> <LI><strong><A NAME="00913" HREF="msg00913.html">[MUD-Dev] Re: Introduction</A></strong>, Adam J. Thornton <a href="mailto:adam#phoenix,Princeton.EDU">adam#phoenix,Princeton.EDU</a>, Mon 07 Dec 1998, 00:55 GMT </LI> </UL> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>