Not key themes anymore

[Russell Nelson <nelson crynwr com>]

Tom Tromey writes:
 > As Elliot says, a port of xkeycaps is on the to-do list.
 > 
 > However, this won't really satisfy the need for key themes.

Right.  In fact, talking about "key bindings" is antithetical to the
Gnome/CORBA concept, at least, as I understand it.  The way you build
up a modern software system is in layers.  The lowest layer is the
hardware.  The next lowest layer talks to the hardware.  The layer
above that provides services like audio mixing, IP, filesystems, and
processes.  The layer above that provides services like audio
playback, TCP/UDP, file management (e.g. ``unlink'' just moves a file
to the trash), and process management.  Above that layer you have
"application" functions, like databases, time tracking, image viewing,
image editing, sound editing, file editing.  Up to that layer, most
operating systems provide a user interface to the whole system.  That
is, an "application" program can use TCP to write a file which gets
dumped to the audio player (e.g. for an mpeg3 player).

CORBA (or any "middleware", which is a horrid name), is an attempt to
take a bunch of "applications", and make them into system libraries
while mixing in object orientation at the same time.  I think this
confuses people.  I think that OO confuses people in *general*.  The
idea is sound.  Maybe we just need a better way to describe it to
people?

IMHO the "proper" way to do system development is to NOT create
applications, but instead to create libraries that build on the
lower-level OS capabilities.  Then, a user interface program accesses
these high-level libraries to expose their functionality to the user.

The way current "application" development works is: that's all bundled
into one program.  It's like the old DOS days where everything had to
be stuffed into one program, because the OS didn't provide any
services to you.  For example, a dialup IP router had to have an
interrupt-driven serial port driver, an Ethernet driver, a TCP/IP
stack, routing code, and a user interface to configure it all.

Someone suggested that the way to expose this functionality is through 
a user-interface description language, which they pointed out is what
XML is, in many ways.  This is a GREAT idea.  Let's examine how gtt
would work this way.

First, gtt would use a library to write log files (maybe syslog is
sufficient, maybe not).  Second, it would know that the log files
contain task switch entries, so it would provide functions to
summarize the various tasks.  It would also know that the things it
logs go into buckets, and it know know about the buckets.

So then, writing gtt becomes a matter of using this library of
functions which track time, which call functions from another library
that knows about log files, and another library which knows about
buckets.  The functions in the "gtt library" get exposed to the user
using the user interface description language (maybe XML, maybe
something else).  It causes user interface events to call functions in 
the gtt library.

So, if someone wants to add something to the gtt program, they can
write their own library, and change the user interface so it calls
into their library.

Or if some program wants to do time tracking as well, it just has to
link to the gtt library, instead of writing its own code.

There's nothing magical about this.  It's just good design that not
many people have picked up on.

-- 
-russ <nelson@crynwr.com>  http://web.crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok |   Freedom is the primary
521 Pleasant Valley Rd. | +1 315 268 1925 voice |   cause of Peace, Love,
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   |   Truth and Justice.