The evolution of MOO (GambdaMOO?)
Shan Hollen
I wish I were a good enough C/socket coder to help. I commend you all
for your fantastic work. It is hugely appreciated.
I know that you guys are very busy and are focused on modernizing the
server and and its language tools, but have you thought at all about
adding support for any of the MUD standard protocols? Stuff like
TTYPE, NAWS, MSDP, MSP and MXP are quickly being adopted by
developers across the MUD community, including those who build and
maintain clients. Scads of clients support many of these protocols,
and a few support them all.
There's a snippet of code out there that does it all. I've
corresponded with its author, and according to him, there's no reason
his code wouldn't be compatible with the MOO server. It's written
purely in C. He says adding it is fairly simple, although doing so is
over my head. He is very willing to answer any questions about the
code, and help anyone interested using it.
Is there any interest at all among those of you who are doing the
coding to incorporate these protocols into the server? Among other
things, it would allow developers to script custom graphical
interfaces for their MOO's on top of widely used clients like MUDlet
and MUSHclient, add features like links, menus and expanded color,
and open MOOs to development for mobile platforms.
Something to think about!
-Shan
Luke-Jr
> I know that you guys are very busy and are focused on modernizing the
> server and and its language tools, but have you thought at all about
> adding support for any of the MUD standard protocols? Stuff like
> TTYPE, NAWS, MSDP, MSP and MXP are quickly being adopted by
> developers across the MUD community, including those who build and
> maintain clients. Scads of clients support many of these protocols,
> and a few support them all.
I don't know a single half-sane client with even MCP support, let alone this
other alphabet soup I've never heard of. In any case, my MOO uses an internal
webserver to provide an AEAM (Async ECMAScript And MOO) web client, so I'd be
implementing both ends of any protocol.
Also, any such implementation is very likely to remain in-db, not in the
server, which is what I'm sure his patch would be.
Shan Hollen
Yeah. No one touches MCP because it's basically a MOO-only protocol,
and in the realm of text-based virtual worlds, the percentage built
on MOO is comparatively non-existent. Which is why I made the
suggestion. I guess I thought expansion of the MOO server into
standards being adopted by the rest of the MUD community would be a
good idea, but I don't know the logistics and I'm not the one writing
the code. I'll just say that there is a large and growing number of
clients out there with support for telnet options that compress data,
handle window sizing, client identification, sound, and the out of
band passing of data between server and client, among other useful
tasks. MUD developers are using these options to enhance and enrich
their products in ways that draw users, which I think is what's
ultimately important.
Just thought I'd throw it out there. :-)
I asked KaVir about in-db vs. server implementation. He said he'd
never coded in MOO, but that he'd guess compiling the code into the
server would be a lot foster.
Luke-Jr
> I asked KaVir about in-db vs. server implementation. He said he'd
> never coded in MOO, but that he'd guess compiling the code into the
> server would be a lot foster.
I'm sure it would, but it'd also be a lot less "pure".
Todd Sundsted
done", although a lot of functionality would also require in-MOO
database hooks to maximize usefulness -- MOO is pretty generic (it's
not specific to RPG gaming, social MUDing, etc.) compared to some
other MUD servers. If you're interested in becoming a better C
programmer, integrating the code would be an excellent way to
learn :-) IMHO. As a first pass, I'd investigate integrating it the
same way I integrated HTTP processing -- consider adding mud_read()
and mud_write() (or something) built-ins that are called on a binary
connection and call the library's functions to set-up/negotiate a
connection, etc. etc.
That said, I really think HTTP + Javascript is the way to build a next-
gen MUD/MOO client. Links, menus, and color, have been supported in
browsers since Mosaic :-) and mobile comes for free. And it opens the
world of MUDs/MOOs to the roughly 2B people who use the web but who've
never heard of telnet :-)
Todd
Michael Munson
I used Todds stunt branch and a local nodeJS/socketIO proxy to make a simple JavaScript MOO client which is as simple as going to http://server/moo -- no special port on even the http request and everything (including the client itself ) is served from the MOO proper.
That really is the future.
Sent from my iPad
> --
> You received this message because you are subscribed to the Google Groups "MOO Talk" group.
> To post to this group, send email to MOO-...@googlegroups.com.
> To unsubscribe from this group, send email to MOO-talk+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/MOO-talk?hl=en.
>
Michael Munson
I used Todds stunt branch and a local nodeJS/socketIO proxy to make a simple JavaScript MOO client which is as simple as going to http://server/moo -- no special port on even the http request and everything (including the client itself ) is served from the MOO proper.
That really is the future.
Sent from my iPad
Luke-Jr
and AEAM client in a git repository... ;)
Todd Sundsted
One more item... take a look at http://207.210.101.162:8888/
This is a proof of concept of a self-contained MOO-based web
environment. The MOO handles the HTTP and a small flash component
allows JavaScript to open a socket to the server. The POC uses a
bastardization of HTTP upgrade to handle the console connection and
authentication, so that once a user authenticates via the web (presses
"Login" in this little POC) he/she will authenticate over the socket
transparently. So, basically, all that's required is the MOO server
(and a small flash socket auth server which will eventually move in-
MOO).
Todd
On Nov 29, 8:09 am, Michael Munson <michael.d.mun...@gmail.com> wrote:
> Resent because I am incapable of hitting reply to all.
>
> absolutely agree. The most innovative M* client in years was Pueblo andnit was really kind of terrible-- but it's idea was good- why invest all this time creating new markup languages like MXP, et all when we already have an incredibly robust markup language in HTML?
>
> I used Todds stunt branch and a local nodeJS/socketIO proxy to make a simple JavaScript MOO client which is as simple as going tohttp://server/moo-- no special port on even the http request and everything (including the client itself ) is served from the MOO proper.
>
> That really is the future.
>
> Sent from my iPad
>
Luke-Jr
> One more item... take a look at http://207.210.101.162:8888/
>
> This is a proof of concept of a self-contained MOO-based web
> environment. The MOO handles the HTTP and a small flash component
> allows JavaScript to open a socket to the server. The POC uses a
> bastardization of HTTP upgrade to handle the console connection and
> authentication, so that once a user authenticates via the web (presses
> "Login" in this little POC) he/she will authenticate over the socket
> transparently. So, basically, all that's required is the MOO server
> (and a small flash socket auth server which will eventually move in-
> MOO).
And Flash on the end-user side. No thanks.
Proof-of-concept AEAM client: http://kids.moo.mud.org/=323/
Josh Benner
style connections from browsers, and it looks like that's exactly what
Luke Jr's client is doing.
On Nov 29, 12:08 pm, "Luke-Jr" <l...@dashjr.org> wrote:
> On Tuesday, November 29, 2011 11:54:46 AM Todd Sundsted wrote:
>
> > One more item... take a look athttp://207.210.101.162:8888/
Tim van Dijen
am still working on an editor.
http://178.239.60.28/
Op 29-11-2011 18:17, Josh Benner schreef:
Todd Sundsted
Does anyone know if any encore guys/gals hang out here?
Todd
On Nov 29, 12:23 pm, Tim van Dijen <tvdi...@gmail.com> wrote:
> I have a similar web-client, with (some) support for MCP implemented. I
> am still working on an editor.http://178.239.60.28/
Matthew Duhan
Luke-Jr
> Meanwhile on the flip side, years ago I developed a complete set of utils
> for Pieblo-ifying/HTML-ifying a MOO. If someone can get a MOO to play nice
> with modern browsers, I have the means to make links clickable, attach
> images and sounds to objects, etc.
What doesn't "play nice" for you? My webserver seems to work fine with any
browser, old or new...
My "web explorer" app actually uses :look_self, and searches its output for
titles/names of objects in contents and exits, making them into links. It's a
bit ugly, so I'd prefer to get some nicer way to do it...
Luke
4K
I'm the keeper of the enCore support site at the Barn.
http://www.encore-consortium.org/Barn/news.html
I'm following these discussions avidly!
Ciao
KJ
Matthew Duhan
Luke-Jr
> Web browsers by their nature aren't really made to handle a persistent
> connection like one used for MOOing. In the past when I've seen in-browser
> attempts to connect to a MOO, the connection constantly reset or wouldn't
> persist, or the links wouldn't work as expected. That's what I mean by play
> nice. Not so much with the web server itself, but with the connectivity.
Ah, well I've always simply done a custom hackjob for that, which seems to
work fine... The server end just waits until it has data to reply to a poll.
If the client times out, the ECMAScript there immediately retries. The server
side does timeout after a few minutes of no retry-poll, but usually the
ECMAScript's "window closed" event tells the server when it's closed. The
downside to all this is that reloading the page resets the connection/session.
> I built my utils to work with Pueblo, so they might need to be reinterpreted
> to work in a web browser. IMO, it would be great to see someone take a
> browser core like webkit and revive Pueblo.
Yes, except done right this time (IIRC, Pueblo had some major bugs with ANSI).
Josh Benner
comet protocol, and it seems to work pretty well!
http://en.wikipedia.org/wiki/Comet_(programming)
Matthew Duhan
Luke-Jr
> Agreed. Anyone up for the challenge?
Maybe in the long run, I'll add it to my webclient...
> I figure in some way it could be hacked up, by using javascript to scan
> click events for MOO command input rather than URLs, and to update
> pueblo-specific sound/image tags to their proper format. I'd rather
> something less hacky though if possible.
The hard part is replacing all the strings with markup internally...
Matthew Duhan
Luke-Jr
> On Thu, Dec 1, 2011 at 10:19 AM, Luke-Jr <lu...@dashjr.org> wrote:
> > On Thursday, December 01, 2011 10:56:32 AM Matthew Duhan wrote:
> > > Agreed. Anyone up for the challenge?
> >
> > Maybe in the long run, I'll add it to my webclient...
> >
> > > I figure in some way it could be hacked up, by using javascript to scan
> > > click events for MOO command input rather than URLs, and to update
> > > pueblo-specific sound/image tags to their proper format. I'd rather
> > > something less hacky though if possible.
> >
> > The hard part is replacing all the strings with markup internally...
>
> When you say internally, do you mean in-MOO?
Yes.
> It will automatically surround names of players, objects, and exits with
> appropriate pueblo-command markup ("look X", "go X", etc.).
I'd prefer to have it in some client-neutral markup language that the MOO can
mangle itself... how do you deal with security issues (ie, not letting just
*anyone* insert images etc)?
Matthew Duhan
how do you deal with security issues (ie, not letting just
*anyone* insert images etc)?
Stephen Gigante
I'm in the process of building a new client, and have been considering using webkit for the output window.
Consider this conversation additional motivation for me :)
-Stephen
--
Luke-Jr
> I'm in the process of building a new client, and have been considering
> using webkit for the output window.
Please be sure to use Qt!
Luke