From jag@doppio Wed Aug 21 09:50 PDT 1996
Date: Wed, 21 Aug 1996 09:52:10 -0700
From: jag@doppio (James Gosling)
Subject: Java API issue
To: dbowen@doppio
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-MD5: hs6xVqxfhf1l05aG+h0k5Q==

Another one for the stack...


------------- Begin Forwarded Message -------------

From ###@###.###  Tue Aug 20 15:29:37 1996
From: Chuck McManis <###@###.###>
To: "'###@###.###'" <jag@Eng>
Cc: "'###@###.###'" <###@###.###>
Subject: Java API issue
Date: Tue, 20 Aug 1996 15:27:42 -0700

If you do get around to the Java API this year :-) one issue I'd like to see 
addressed if possible
is FileInputStream.read();

In particular, where input stream editing fits in.

This came up when I wrote a SerialInputStream class that read characters from a PC 
serial
port. I wanted to connect System.in and System.out into the serial port. So I created 
a 
buffered stream with new BufferedInputStream(new SerialInputStream("com1:9600/8n1"));
and assigned it to System.in. That worked sort of but there were two problems:
	1) Line editing wasn't dealt with, (while ^h echoed, it also went upstream.)
	2) spontaneous input wasn't possible (aka raw mode) as in {
		while (true) {
			if (in.available() != 0)
				return in.read();
			doSomeOtherThing();
		}

This isn't an issue in Applets (unless you create interactive serial streams for 
them) but it
is a major compatibiltiy issue with Applications. 

This is particularly true when different platforms specify different line editing 
disciplines
(is ^h a delete or is <del>?, what does ^u do? etc)

There is another related can of worms which is supporting several applications 
running in
the same VM with different ptys. I'm sure some of this has come up in the Kona work
and probably been dealt with. I hope it gets fed back into the API.

Ideally, I'd think that line editing and the notion of a controlling pty could be 
encapsulated
in a java.lang.Console class. A partial definition might be:
public class Console {
    /** Create a new console connected to these two streams. */
    public Console(InputStream in, OutputStream out);

    /** Createa  new console connected to 'stdin/stdout' */
    public Console();

    /** read one line of input (with line editing) from the console. */
    public String readLine();
   
    /** print a line to the console */
    public void printLine();

    /** return this consoles input stream */
    public ConsoleInputStream inp();

    /** return this consoles output stream */
    public PrintStream out();

    /** return this console's error stream */
    public PrintStream err();
}

ConsoleInputStreams could define the line editing discipline. The reason we have
to combine both an inputstream and an output stream into the class is that for
line editing the user may type ^r and expect the current input buffer to be replayed.
The console has to know where to send it. Thus the constructor for ConsoleInputStream
would take both an InputStream object and an OutputStream object.

This will also solve the problem that other threads/applications in the same VM can
stomp System.in and steal the tty from another application.

--Chuck
------------- End Forwarded Message -------------