I thought a bit more about the terminal project.

I realized that as a prerequisite for terminalizing floppies, CD's, USB
keys, digital cameras, and other removable media, we must revise the
filesystem (or at least the mount command) to allow users to mount
volumes on (sub)directories of their home directory.  For security's
sake, the sysadmin would specify which types of devices are allowed and
would enforce mount options such as nosuid, uid, and gid.

Removable media could be mounted inside ~/mnt, possibly with the help of
an automounter.  All filesystem activity inside these mount directories
would be translated into "terminal" control codes which would have the
effect of accessing the physical media present at the user's machine.
For this to work we'd make a termfs filesystem kernel module.

I imagine that with such a setup, the user could place a short login
script in ~ to attempt to mount my distributed filesystem over the top
of ~, then chain to the rest of the login script as contained in the new
filesystem.  Other funky filesystems, including "userland" filesystems,
could also be mounted this way.  What's important is that the sysadmin
be able to enforce certain rules to avoid security holes.  Then it
becomes possible for user code to safely implement a filesystem.

So let's not do the floppy thing yet.  Ditto 3D.  Instead let's start
with stuff we actually know about. :^)

I need to check out the structure of the X protocol since I think we
would use something similar.  A compact binary protocol is appropriate
in situations like these.  Come to think of it, the current protocol
(I'll call it ANSI, since it's implemented in MS-DOS with ANSI.SYS) is
"almost binary".  Even though it's ASCII-encoded, it's very difficult to
read and write and requires having a lookup table for reference and some
way of typing a literal ^[.  Also, X's protocol appears to be
extensible, and we certainly need this feature.

First we must think about the basic design.  Since we'll be coding this
in userland, our terminal system will communicate with client apps using
pseudo-tty pairs.  And since we want to avoid mucking with the kernel,
the terminal daemon will talk to the graphics card using the existing
tty interface, speaking the existing protocol of escape sequences,
termios calls, and ioctls.  We'll fix this in the future by creating
kernel modules giving more direct access to display hardware, but for
the moment speed is not important.

In the process we should give some thought to the VC switcher, which
would initially be similar to GNU screen.  Later on, as support for new
devices (graphics display, sound, joystick) are added, the VC switcher
would become something more, and it would need renaming. :^)

After covering basic design issues, we need to work on supporting all
(reasonable) existing terminal capabilities.  So let's run down the list
in console_codes(4), ncurses(3x), termios(3), and slang(?), eliminate
overlap, and put what's left in our program.  For each feature, we need
a client API function, a packet format, server code to receive the
packet, and server code to actually implement the feature.

Then we should code an ANSI emulation module so that existing programs
can continue to run without modification.  It may seem shameful to
translate from ANSI to something else then back to ANSI, but that's
pretty much what GNU screen does anyway.

After that, we should add support for the mouse and the joystick, which
are easily recognizable as input devices.  From there we can add sound
and graphics, both of which may require enhancements to the VC switcher.
And after that, we can add an X emulation module, and window management
functionality would go in the VC switcher.

Probably enough for now...  Please comment.