bomb shell (fwd)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


---------- Forwarded message ----------
Date: 18 Mar 1999 18:10:24 -0000
From: Lar Kaufman <lark@xxxxxxxxxxxxx>
To: blinux-develop-request@xxxxxxxxxx
Subject: bomb shell

I apologize for making remarks that may have appeared "political" in
trying to examine what I perceived to be a political bias.  The suggestion
of political arguments made me rethink an assumption on my part, however.
I'd like to suggest a different line of examination regarding the basic
user interface that might once and for all preserve user access to the
OS, if I could get some feedback from "those who know" about some specifics
of this and that technology, since I think I may have a novel solution to
the accessibility problem.

Instead of asking "what other non-proprietary solution offers as flexible
solution to user access as emacs" I should have asked "how can we give
Linux low-level support for a rich, non-proprietary user interface?"  The
answer that came up when I asked that was not emacs, but XML.  If Linux
were capable of presenting information in the form of XML structures, it
would be a simple matter to plug in, at the shell, desktop, or application
level, a web browser interface; the operating system would not have to make
assumptions as to the user's mode of access except to deal with the installed
hardware in traditional Unix ways.  Let me hasten to add that full XML 
need not (probably should not) be supported, but useful structural markup
should be supported.  For example, Linux would not send a message tagged as
"bold" information, but it could send a message tagged with "emphasis". 
And Linux need not then concern itself with how the information it is 
presenting will be rendered for the user, only that it was sent to devices
that are supported by default or user-chosen utilities to render it appropriatedly.
The tricky part is to define what subset of XML tagging is *necessary* for
OS-user interactions and what tag handling (recognition/stripping/ignoring)
Linux will perform on input from the user.  And, if necessary and appropriate,
defining new tags to submit to the W3C to support open systems accessibility
at the lowest level.  Getting an English voice message output to a sound card,
for example, would not be difficult, but getting a vocal response returned
to Linux and recognized as a choice or command is a tougher problem that 
might best be handled by making the user's shell, desktop, or browser smart
enough to process the signal into the needed data for Linux to use.

Does this seem viable without significantly distorting the kernel?  

"The sum of all we drive at is that every man may enjoy the same rights that
are granted to others." -- John Locke, 1689, A Letter Concerning Toleration

[Index of Archives]     [Linux for the Blind]     [Fedora]     [Kernel List]     [Red Hat Install]     [Red Hat Watch List]     [Red Hat Development]     [Gimp]     [Yosemite News]     [Big List of Linux Books]