Re: web inherits UNIX console?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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.

It will do, perhaps.  It will not be nearly as good, in many respects,
for almost all of even that 1/2 to 3/4 - except, of course, web
browsing, and even that only to the extent that the web browser in
question is (which, IME, isn't a very great extent).

> HTML5 + DOM + JavaScript give you great display capabilities, and an
> improved mouse+keyboard abstraction.

This sounds to me like "let's reinvent Display PostScript, badly".

> Also, web technology is improving where TTY is standing still.

You appear to be interpreting the latter as "stagnating" or something
similar.  I think "got it right" comes closer.

> I think that to start, you could use a standard HTTP server.

Requiring "a standard HTTP server" merely to get GUI console
interaction is absolutely hair-raising from a security standpoint (and
almost as hair-raising from a bloat standpoint).

> You are in a good environment to type an email.

Actually, that sounds like a pretty miserable environment to type an
email - or, else, a pretty miserable environment to type anything else.
When I write email, my editor is configured rather differently from how
it's set up for most other things, and for good reason.

> #1: the new web environment, unlike a CLI, is a *direct manipulation*
>     interface.

This reinvents some of the worst problems of GUI interfaces:
specifically, unscriptability and the inability to manipulate things
that cannot be displayed.  For exmaple, you appear to want to replace
pipelines with massaging a section of the display with multiple
commands.  This is fine, until one of those commands produces a
half-gig of data which the next command distils down into something
usably small.  I also don't see how your proposal would handle
backgrounded commands.

> 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.

Actually, it seems to me you would be losing two of the most important
and successful of those principles: "one job per program" and "run the
user's preferred tool for $JOB" ($EDITOR is a simple example of this;
$PATH is a more elaborate one).

> The new interaction is more direct and document-centered.

Which is - or at least may be - fine, if you're doing something
document-centred.  It pretty much sucks for everything else.

> It rolls into one web app the functions of an editor, a command
> shell, a terminal multiplexer, and a terminal.

Indeed.  But it does so at the same prices exacted by every other "roll
a bunch of stuff into one": it is difficult-to-impossible to replace
individual pieces, and it does a mediocre job at most-to-all of those
tasks, for some substantial fraction of the user base.  (The latter is
unavoidable because it is not possible for the same interface to be
good for everyone.)

> 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.

The flip side of interactivity is unscriptability - another deviation
from a very important piece of Unix philosophy.

I wouldn't say the power is greater than a traditional command-line.
I'd say it's _different_: greater for some kinds of tasks, worse for
others.

This would be a very interesting experiment.  Along about version five
or six it might have evolved into something usable, and at that point
it might be a good idea to put it into NetBSD.  In its present form, I
don't think it should have anything more to do with NetBSD other than,
possibly, being built atop it.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B