[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

4675: Re: [MUD-Dev] Clients

[Full Header] [Plain Text]
From: coder@ibm.net
Newsgroups: nu.kanga.list.mud-dev
Date: Sun, 22 Feb 98 16:24:53 -0800
References: [1]
Organization: Kanga.Nu
On 17/02/98 at 09:33 PM, Katrina McClelan <kitkat@directcheck.aries.net>
said: >On Tue, 17 Feb 1998, Travis Casey wrote:

>That's one of my problems in general with clients and the issue of telnet
>is bad.  I'll be the first to agree that telnet is a very silly protocol.
> However, it's supported on almost any platform without extra downloads
>or such.  The solution I'd eventually use, and that I have mostly
>implemented is a [psuedo] terminal server, terminfo, and lib curses. 

I happen to know a bit about curses and have been a strong proponent of it
on this list.  Note: I've written two curses implementations, was involved
in the XOPEN conformance testing of HP's curses library for HP-UX, and
have written a number of commercially marketed applications which used
curses interfaces.

>I suppose that curses limits features to text, but with full screen manipulation >of it, it's still quite versitile.  

True.

>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.

How does the server know what terminal type the remote client is
emulating?  Many telnet clients very poorly or partially implement even
the VT-* terminal types.  Additionally it is often quite difficult (and
few know how) to set the desired terminal type in quite a many telnet
clients.

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.

That given, curses works very nicely.

--
J C Lawrence                               Internet: claw@null.net
----------(*)                              Internet: coder@ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...