Subject: Proposed function: notify_ascii()

From: Gilmore <[email-masked]>
Date: Sun, 25 Oct 1992 15:19:41 -0800

This seems like an extremly easily-programmed function: a variant of notify
which would allow one to send an ascii character, such as an ESC for the
implementation of vt100 or ansi command sequences.  Then one would be able to
create an object $screen_utils with verbs like :up, :down, :color, :clear, and
so on, and perhaps a prop $player.term_type which this would access.  At
any rate, it seems like a trivial capability to add, although I certainly have
no experience with hacking the server.

Could someone tell me why this would be a bad idea?

				- Gilmore

---

From: Judy Anderson <[email-masked]>
Date: Sun, 25 Oct 1992 16:58:00 -0800

Date: Sun, 25 Oct 1992 18:19 EST
    From:	Gilmore <[email-masked]>

				    - Gilmore

The reasons that it's generally a bad idea to allow arbitrary escape
sequences to be sent to your terminal are generally those of security
assumptions by the specific terminal.  In old HP terminals (HP26xx's)
you could program a softkey via escape sequences and make the terminal
pretend you hit a softkey, in effect, forcing the user to do arbitrary
typein of your choice from their userid.  Bad idea...  I don't know if
there are still other terminals with this sort of capability, but I
imagine there are.  In the absence of malicious users, such capabilities
are a boon (and presumably HP didn't think about interactive games
played with people from around the world when they designed their
terminals...)

If you are running on a terminal which you *know* won't be compromised
by such tricks, then there really isn't any risk.  (Well, someone might
make it print in chartreuse on mauve and you'd barf, but other than
that...)

---

From: Roger Crew <[email-masked]>
Date: Mon, 26 Oct 1992 15:24:37 -0800

Actually the real objection to this is more on philosophical grounds rather 
than security grounds.  For this to be useful, the MOO server would
then have to be informed about the proper escape sequences to use to
perform the desired operations on *every* kind of terminal in
existence.  

Granted, the argument could be made that LambdaCore is so bloated now
that no one would notice the addition of /etc/termcap.  However, the
problem of keeping the proposed LambdaCore terminal database (call it
"MOO-termcap") up to date is actually slightly *worse* than the
problem of keeping an /etc/termcap up to date, since we'd be talking
about maintaining centrally something that is best maintained locally

    Loser pages, "Hi Haakon, I need a new MOO-termcap entry for hazeltine-1000-
      with-a-fried-somethingorother-card so that all of these neat LambdaMOO 
      display thingies will work with my braindamaged terminal."  
    Haakon responds with much enthusiasm.

Life is much easier if only the client program has to know about
manipulating the terminal.  This is not to say that wanting to do
simple terminal operations from MOO-code is a bad thing; merely that
there are much better ways to do it than teaching the MOO server about
all terminals in existence and having the MOO server send the right
escape sequences directly.  In particular, we shouldn't be contorting MOO
to deal with the limitations of the telnet client.

The right way to do this is to have one or more published protocols
for doing screen manipulations on clients and then a property on each
player specifying which protocol is in use.  E.g., one could have a
protocol like

   ~~   =>  ~
   ~P   =>  highlight on
   ~Q   =>  highlight off
   ~L   =>  clear the screen
   ~^J  =>  end of line without a return (for queries...)
   ...

and then we spend our effort on clients that know how render particular 
~-sequences.  There would still be a "MOO-termcap" of sorts but it would 
only refer to protocols and not be tied to any particular hardware.

Note that if graphical muds are what you really want, then you
probably want to be using X or something of that ilk for your protocol, 
though this would have to wait for another order-of-magnitude increase 
in cross-country network bandwidth.  This would be a completely different
animal though...
--
Roger Crew
Internet:   [email-masked]
LambdaMOO:  Rog

---

From: Mike O'Brien <[email-masked]>
Date: Mon, 26 Oct 1992 15:43:08 -0800

>manipulating the terminal. ...
>player specifying which protocol is in use.

This was first invented years ago, in the Arpanet SUPDUP protocol.  It
specified just about all the cursor-motion stuff on alphanumeric
terminals, and used a server-client pair to have the translation to
actual terminal codes done at the client end.

For whatever reason, this never caught on, and SUPDUP has recently
been officially decomissioned by those whose job it is to throw
away old Internet protocols.