Re: web inherits UNIX console?

[David Young <dyoung%pobox.com@localhost>]

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
use cases, a browser will do.  HTML5 + DOM + JavaScript give you great
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
JavaScript that controls the local display and speaks to the server.  If
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[1].  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
different.

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.
As you type, the JavaScript synchronizes the document state with your
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[2] 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
differences:

#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[9]).  Evaluating a command replaces the command
    input with the command output and hides the command & arguments[7].
    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[4].  To reverse command evaluation,
    strike the undo key (for discussion, undo is Control-U [5]).  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[8].  Then,
    edit the command, its input or arguments, and re-evaluate.

#5: under some circumstances[3], 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!)
    markup.

    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[10] 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[12] 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
UNIX.

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.

Dave

[1] This is the *initial document*.  You can create new documents with a
    key command, but I won't get into that here.

[2] 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.

[3] 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*.

[4] 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.

[5] Redo is Control-Shift-U, also for discussion purposes, only.

[6] 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.122.4927&rep=rep1&type=pdf

[7] 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.)

[8] 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
    Control-Shift-G.

[9] We bind the command key to Control-Enter instead of Enter because
    Enter is the key that inserts a carriage return.

[10] I'm almost out of traditional modifier keys.  Let's call this one
     Meta.

[11] 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.

[12] 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[11].  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.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 344-0444 x24