[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: web inherits UNIX console?
On Thu, Sep 15, 2011 at 09:39:18PM -0400, Matthew Mondor wrote:
> But I'm not really sure how far you'd want to push the idea. If you
> mean that a totally novel web interactive interface could replace both
> X11 and console
Yep, an interactive web interface that can replace X11 & TTY.
I don't know about replacing X11, but I think that for 1/2 to 3/4 of X11
display capabilities, and an improved mouse+keyboard abstraction. Also,
web technology is improving where TTY is standing still.
> , I think that it's a good research area. For now
> unfortunately if the client-side is BSD you still need a heavy X11 +
> modern browser setup (with its security implications thrown in)...
It is too bad about that.
> For the server-side a possible implementation might be a special HTTP
> daemon application connecting/proxying to the various
> application-specific SOAP/RPC/FastCGI-like services, applications
> designed for your particular protocol rather than for something like
> tty, Gtk, QT, Gnome or KDE...
I think that to start, you could use a standard HTTP server.
I should say first of all that the following draws heavily on others
ideas[6, 8]. Secondly, I do have in mind for the web interface neither a
warmed-over CLI nor a traditional GUI.
Here is the way that I currently envision the interaction: you
load a login page in your browser. Say that the login page is
https://yourhost.example.com/workspace/<id> where <id> is variable (more
on that in a bit). You enter your login & password and submit that to
the server. The server sends your browser a web page that contains
this is the first time that you have logged in using this particular
<id>, the web page contains a blank white rectangle with a cursor and
a faint border. If you have logged in using <id> before, then the
state of your last <id> session is restored, including the content of
the document, your undo/redo history, text selections, and the location
of your cursor. You can pick up precisely where you left off--it's like
screen(1) or tmux(1) in that way, but the implementation details are
Now what do you do? You just type. You are in a lightweight
word-processing environment, writing in an anonymous document. You
have some standard tab stops, line wrapping, and basic commands for
cursor/viewport motion, cut & paste, and editing bound to familiar keys.
NetBSD box so that you won't lose anything if your browser crashes. You
are in a good environment to type an email.
I realize that this doesn't sound much like operating a UNIX command
shell, yet, because for one thing, there are no commands! Bear with me.
First let's mention the UNIX environment. Connected with each
document is a current working directory and the usual environment
variables (e.g., SHELL). You can invoke traditional UNIX commands in
a traditional UNIX environment. Command invocation works differently
in the web environment than in a CLI, however. There are several
#1: the new web environment, unlike a CLI, is a *direct manipulation*
interface. You will not ordinarily invoke commands on a reference
to the input such as a filename (although you can if you want to),
but you indicate the input itself (by selecting some content), you
indicate the command and its arguments (by typing and selecting
them), and then you evaluate the command on the content (by typing
the command key, which for the purposes of this discussion we bind
to Control-Enter). Evaluating a command replaces the command
input with the command output and hides the command & arguments.
The web interface distinguishes command output from "ordinary"
content using a border, inobtrusive marks, or a visual filter.
#2: the second difference from a CLI is that the command output is
not ephemeral as it is in a TTY, but it is interpolated into the
document, where you can apply another command to it. In this way,
commands can be *composed*.
#3: command evaluation is *live* whenever that is possible. If I invoke
'ls', for example, that should interpolate a listing of the current
working directory into my document. Should the listing change, the
new listing should replace the old listing. A command-key modifier
should disable live evaluation (for discussion, say non-live
evaluation is Control-Shift-Enter).
#4: command evaluation is *reversible* or *modifiable* insofar as it has
no irreversible side effects. To reverse command evaluation,
strike the undo key (for discussion, undo is Control-U ). One
way to modify a command, its input, or its arguments, it to reverse
evaluation, edit the command, input, and arguments, and re-evaluate.
The other way to modify a command is to highlight the command output
and invoke a command that unhides the command and arguments and
temporarily displays the command input beside the output. Then,
edit the command, its input or arguments, and re-evaluate.
#5: under some circumstances, you can edit command output (i.e.,
insert & delete text). Ordinarily, editing the command output
modifies the command *input* and re-evaluates the command.
In order to modify command input based on editing commands
applied to the output display, we need to introduce a new type
of UNIX filter, the "type-through filter," which passes editing
capabilities to the next pipeline stage. The editing capabilities
should probably be embedded in the output stream as (gulp!)
By composing type-through filters, you can build up sophisticated
functions. For example, you may create a uncomplicated word
processor that perfectly suits your individual needs by composing
a couple of type-through filters: one filter interprets TeX or
mdoc markup and converts it to display markup, and a second
filter marks up spelling mistakes.
#6: the system may insert filters to improve the display. Say that you
evaluate 'cat fido.jpg'. This is not ordinarily a useful thing to
do. If you really mean to do it, then do: add the modifier to
your command key that means, "treat this command output literally."
If you don't add the modifier, then let's see a picture of our
beloved Fido, please. (You say Fido has red-eye? Select the image
and apply the red-eye filter.)
So you see that I do not propose to replicate the traditional
command-line conversation in a browser window, but I propose to
reinvent the UNIX interaction style while sticking with UNIX principles.
The new interaction is more direct and document-centered. It rolls into
one web app the functions of an editor, a command shell, a terminal
multiplexer, and a terminal. You can use the new interface to build
sophisticated functions from simple functions, and the power and
interactivity of composite functions is greater than in traditional
It's possible that the web is not the best available medium for the UI
overhaul that I have outlined here. Considering the web's capabilities
and its pace of improvement, though, it deserves careful consideration.
 This is the *initial document*. You can create new documents with a
key command, but I won't get into that here.
 Or maybe there is a current working directory (cwd) connected
with each character or paragraph. It is an open design question.
Whichever way it is, the cwd should either be called up for display
or interpolated into the document with a key command, or displayed
in a status bar.
 Live command output should be "read-only", or else editing the live
command output should replace the live command (re-)evaluation with
a snapshot of the current output and edit the snapshot, or else
editing should modify the command *input*.
 Transmitting data to a remote host is an irreversible side effect.
Insofar as a command has local side effects, we need to capture
those in the undo/redo history so that they can be reversed---this
may be a big challenge for implementors.
 Redo is Control-Shift-U, also for discussion purposes, only.
 There are variations on this theme, controlled by modifier keys.
For example, Control-Alt-Enter replaces the command input with the
command output, but it does not delete the command and arguments.
(This is just one possible key binding.)
 This key command comes from the Canon Cat, where it is called
"unpocketing." Evaluating an expression is called---you guessed
it---pocketing. The Canon Cat was the creation of Jef Raskin's
company, Information Appliance. I've drawn on Raskin's book,
_The Humane Interface_, for inspiration and many of the ideas in
this re-arrangement of the UNIX command shell. For the purpose
of this discussion, pocketing is Control-G, and unpocketing is
 We bind the command key to Control-Enter instead of Enter because
Enter is the key that inserts a carriage return.
 I'm almost out of traditional modifier keys. Let's call this one
 Ordinarily you cannot backspace over the command prompt. Maybe we
need both hard characters that backspace bounces off of, and a hard
backspace (Ctrl-Shift-Backspace?) that erases even hard characters.
 If you require a traditional command-line conversation with a
prompt, we can provide that in this environment. To get a prompt,
type one---maybe you do that by inserting a "special" greater-than
sign, Ctrl-Shift-. on a U.S. keyboard. To get rid of the prompt,
backspace over it. Pressing the command key evaluates all
of the text between the previous prompt and the insertion point,
interpolates the command output on the following line, and inserts
a prompt on a new line after the command output.
David Young OJC Technologies
dyoung%ojctech.com@localhost Urbana, IL * (217) 344-0444 x24
Main Index |
Thread Index |