|[dsdp-tm-dev] RE: Target Management Project - Undergraduate Level thesis to Politecnico di Milano|
Now, could I get outputStream and InputStream of the process (with getOutputStream and getInputStream respectively) and join them to my VT100Terminal through getOutputStream and getInputStream of new IhostShell interface?
Yes this seems exactly like the right thing to do!
The one thing to consider or decide will be, who should do the character
encoding: The Service (LocalHostShell / TelnetHostShell / SshHostShell)
or the Terminal.
You may know that the plain OutputStream just writes bytes and byte
arrays, whereas Java uses Unicode representation of characters internally.
At some point, a conversion needs to be made to convert Unicode into
the Shell's understanding of how characters are represented by bytes.
In the LocalHostShell, the OutputStreamWriter does exactly that: It is
the bridge between the Unicode characters and the shell's bytes.
If you look at the SshHostShell constructor, you see how it constructs
the OutputStreamWriter based on the specfied encoding, and passes
it into the SshShellWriterThread.
I'm not yet exactly sure whether it's better to surface the internal
(byte-oriented) outoutStream through the new IHostShell interface,
or better surface the (character-oriented) Writer. My feeling is that
the outputStream will be better, because this allows for verbatim
characters to be sent, which is necessary when using a program
like lrzsz to transfer files to the remote through x/y/zmodem protocol.
The downside of surfacing the outputStream is that the Terminal
needs to care for proper encoding itself, both on the input and
on the output. Currently, the terminal does not care for encodings,
so that would be another small feature to be added to the Terminal
when it's not provided from RSE.
Probably it would even make sense to surface _both_ the byte/streams
based interface _and_ the character/writer based interface.
Back to the top