[MUD-Dev] Clients

[J C Lawrence]

On Mon, 23 Feb 1998 20:50:51 PST8PDT 
Katrina McClelan<kitkat at directcheck.aries.net> wrote:

> On Sun, 22 Feb 1998 coder at ibm.net wrote:

>>>Particularly if you use ncurses and expect (partually dangerous)
>>>the the receiving client supports colors in some way or another
>>>(doesn't have to be vt100 with ncurses).
>> 
>> Nope, the core problem with implementing curses support in the MUD
>> server is terminal definition.  In the classical case this was not
>> a problem as the terminal type was defined by the application's
>> environment ($TERM, terminfo, termcap and company).  These
>> resources and that definition ability are not available for a
>> client connecting directly to a port on a server.
>
> They are as much as it is connecting to port 23 is on a UNIX box.

Correct.  My wording was sloppy.  Given well written telnet clients,
that data is available.  I'll leave the survey as to the popularity
and number of well written telnet clients to the reader.

Note: I've found a great number of telnet clients don't even do VT-100 
properly, even if they claim to.  

> The telnet protocol is supposed to be able to pass term type
> (TELOPT_TTYPE == 24).  I agree that some telnet programs are quite
> stupid about this.  However it's not too hard to find a client that
> works sanely in this regard.

<nod>

I can't comment on the difficulty for the windows crowd, but it seems
to ber prevasive.  I also note that until fairly recently HP-UX'es
telnet would predictably lie in response to the query.  I haven't
checked Irix 6.5 (running here), Linux, or Solaris yet, but I'd hope
for something a bit smarter.

>> Additionally it is often quite difficult (and few know how) to set
>> the desired terminal type in quite a many telnet clients.
>> 

> Aye, I suppose you'll always have people that don't have a clue.
> These same people will be the ones that have trouble downloading a
> client too *shrug*

>> The next problem is simultaneously supporting multiple terminal
>> types from a single executing binary.  Many curses implementations
>> handle that extremely poorly, almost forcing you to require all
>> clients to use a single terminal definition.
>> 

> Freely availible, ncurses does a fairly good job of doing this.  It
> is distributed with a terminfo database, can read from this database
> in a user defined directory (if you lack root access to just install
> it), and takes arguments to newterm to define which term type to
> use:

>      SCREEN *newterm(char *type, FILE *outfd, FILE *infd);

>      .....The routine newterm() should be called once for each
> terminal.  It returns a variable of type SCREEN * which should be
> saved as a reference to that terminal.  The arguments are the type
> of the terminal to be used in place of $TERM, a file pointer for
> output to the terminal, and another file pointer for input from the
> termi- nal (if type is NULL, $TERM will be used).  The program must
> also call endwin() for each terminal being used before exit- ing
> from curses.  If newterm() is called more than once for the same
> terminal, the first terminal referred to must be the last one for
> which endwin() is called.

>> That given, curses works very nicely.

> Yeah, the only real problem is a client telnet that does not support
> negotiation of term type (which it is SUPPOSED to).

You miss the key restriction.  Yes, you can call newterm() and company
to do the reconfiguration.  The problem (and I don't know if ncurses
solves this) is that many of the curses libraries (aecurses, BSD
curses, xcurses, dcurses, etc) I've worked with historically used
global data for the screen structures.  Thus the library was limited
to supporting only one screen definition at any one instant.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...