From: hawkeye@glia.biostr.washington.edu (Ken Keys - TF Dude)
Newsgroups: rec.games.mud.misc
Subject: Re: Client/server protocol for LP prompts
Date: 27 Jan 93 18:36:55 GMT
Organization: University of Washington
NNTP-Posting-Host: glia.biostr.washington.edu
Keywords: client server prompt protocol

In <44072@sdcc12.ucsd.edu> djohnson@cs.ucsd.edu (Darin Johnson) writes:

>>The Solution:
>>The server can append the TELNET protocol sequence IAC GA (Go Ahead) to
>>lines not otherwise terminated (i.e., prompts).  A client can then
>>immediately determine how to interpret a block of text:
>...
>>I don't see any problems in this new method.

>Well...

>a) All the output statements that do not have a carriage return
>   at the end will have to be examined to determine if they
>   are a prompt or not.  Unless your client is willing to accept
>   making an occasional mistake either way.

What's so hard about that?  The server can do a simple check before the
write() or send(), and append IAC GA if it fails.  It would probably
take one or two lines of code.  The only difficulty I can is if it's
possible to transmit partial lines that aren't prompts (which is
bad design, IMO, it should use some sort of buffered I/O).

>b) Is it important enough to make this change?  Why not just display
>   the partial text, then place the cursor after it?  Then if more
>   text comes in later, display that, move cursor, etc.  If the user
>   had typed text in the meantime, move the text to the new cursor
>   position.  (is that easy in tinyfugue?  I haven't looked at it)

>   (my problem here is that I'm unsure why you really need to know
>   exactly if it's a prompt or not - it was a simple matter in my
>   emacs client)

In visual mode, TF has an input window and an output window.  Normal
lines are displayed in the output window, and prompts are displayed in
the input window.  So TF needs to know (or make a guess) before it can
display the text.  VaporTalk does the same thing, I believe.  Even in
non-visual mode, TF redraws the prompt nicely if the current line is
overwritten by incoming text.  Also, TF has the option of running
periodic automated processes based on when prompts are received.

>c) It's just more characters that end up getting ignored by everyone.
>   (assuming it doesn't mess up things that aren't strictly telnet
>   complient - including clients *and* telnet implementations)
>   For example, MudOS added extra telnet options for character
>   mode, involving adding extra filters to ignore them (twice,
>   since the first time I mistakenly assumed no one would be
>   silly enough to every turn that mode on).  It's minor, but
>   it is annoying.

>   (and ECHO isn't ignored by all clients.  Most clients can't just
>   simply ignore stuff it doesn't understand, instead they have to
>   filter them out so they don't cause terminals to mess up)

What I meant was, ignoring GA probably wouldn't cause any new problems
that weren't already caused by ignoring WILL ECHO.  (I admit, this part
isn't "clean", but it seems pretty harmless.)  If it does cause
problems, they could be avoided by requiring GA transmission to be
explicitly enabled (either by a flag on the player object, an explicit
command by the player, or some negotiation between the client and
server).

-- 
--
Ken Keys, aka Hawkeye
Master of the Fugue
kkeys@ucsd.edu or hawkeye@ucsd.edu