Subject: Re: ideas for the next big release of MOO server

From: paolo petta <[email-masked]>
Date: Tue, 18 May 1993 15:20:03 -0700

[original message by Chad Wilson ]
> 
> I have a short list of items i would like to see in the next BIG release
> of the MOO server (2.0?).
> 
> ...

Would it be difficult to introduce a `standard error stream' for outputs
(i.e. notify_err(), for example) ?  Its output should be merged with
the `standard output stream' (notify()) by default, but be discernible
at the client's request (i.e. by setting some property...). Would it
bog down the server too much?

That stream would/should be used for all those `error messages' which
are currently output via notify() (usually player:tell()) - for lack
of a different means.

I am pondering some ideas for a `2-dimensional' ```user-friendly'''
client (sg. like `curses-based' in UN*X - ugh!), and this would come in
handy... Then again I guess I am far too unexperienced to make such
requests, yet: please do excuse me if this is downright silly 8-(

Thank you!

pAolo
--
paolo petta                                            +43-1-5336112(Tel)
Austrian Research Inst. for Artificial Intelligence    +43-1-5320652(Fax)
Schottengasse 3, A-1010 Vienna, Austria, Europe     [email-masked]

---

From: Pavel Curtis <[email-masked]>
Date: Fri, 21 May 1993 09:44:19 -0700

> Date:	Tue, 18 May 1993 15:20:03 -0700
> From:	paolo petta <[email-masked]>
> 

The approach we're taking in the Jupiter system to such a need (i.e.,
multiplexing the client's byte stream to the server) requires no server changes
at all.  We simply have prefix the appropriate lines of output with some
special string that the client recognizes; these lines are then treated
differently from normal output.

If you're concerned about security, you can also have the client, on startup,
give the server a special `key' string that must accompany all `out-of-band'
communications.  If the key is stored in an inaccessible place in the database,
spoofers won't be able to make the client believe it's hearing something
special.

	Pavel

---

From: [email-masked]
Date: Fri, 21 May 1993 13:23:00 -0700

> We simply have prefix the appropriate lines of output with some

maybe i'm being a potatoehaed, but why can't you use the socket to just send
out-of-band (OOB) data using the internet protocol:  as MSG_OOB - flagged
'send's.  Any client that isn't ready for this special protocol could be
recognized and setsockopt could be used to set it SO_OOBINLINE, thereby sending
things as one stream.

the big reason _I_ would support this (especially if i were writing a client
or server using your protocol) is that a process can be set up to receive
a signal when OOB data arrives from a socket ... so you'd only have to deal
with these 'special' messages when they arrive ... in a separate signal
handling routine.  if someone wanted to use this 'error' channel for
curses/windows based messaging, graphics messages, etc... it would be ideal
since it wouldn't get bogged down behind reams of text that may be clogging
up the 'main' socket channel.

-traumahound

---

From: Pavel Curtis <[email-masked]>
Date: Fri, 21 May 1993 14:06:57 -0700

> Date:	Fri, 21 May 1993 13:23:00 -0700
> From:	[email-masked]
> 
> out-of-band (OOB) data using the internet protocol ...

The best reason is that this would let out a lot of clients that don't
understand OOB data, including GNU Emacs.  Yes, as you point out, these clients
could be changed to do the setsockopt() call to put the OOB data inline, but
that's a hassle.  The main advantage you cite, keeping OOB data from being
stuck behind a lot of random textual data, does not appear to be an issue for
us in our tests so far.

	Pavel