From owner-freebsd-current  Wed Jun  5 17:03:41 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id RAA19087
          for current-outgoing; Wed, 5 Jun 1996 17:03:41 -0700 (PDT)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA19081;
          Wed, 5 Jun 1996 17:03:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id RAA28586; Wed, 5 Jun 1996 17:02:02 -0700 (PDT)
To: Jake Hamby <jehamby@lightside.com>
cc: John Fieber <jfieber@indiana.edu>, Keith Bostic <bostic@bsdi.com>,
        current@freebsd.org, jhs@freebsd.org, terry@lambert.org
Subject: Re: editors 
In-reply-to: Your message of "Wed, 05 Jun 1996 14:34:57 PDT."
             <Pine.AUX.3.91.960605142028.18110A-100000@covina.lightside.com> 
Date: Wed, 05 Jun 1996 17:02:02 -0700
Message-ID: <28584.834019322@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> would be somewhat like training wheels:  You would have tutorials (or 
> dare I say "wizards" :-) to help you out when you are still learning (you 
> ask it, "How do I create a new account?" or whatever), but on the other 

Erm, I don't really like that approach.  I'll elaborate below.

> Here would be the key features you'd want:
> [standard HTML + CGI interface manager idea elided]

Yes, this is just the latest incarnation of the "external UI driver"
idea that's been hovering around UNIX since the very beginning.  It's
not even necessarily such a bad idea, as the folks at Empac
(http://www.empac.com) have shown, but it has some definite
limitations and there's always the problem of "interface creep" (not
the one behind the keyboard :) when new UNIX tools are added or
changed.  I think that it's only a comb-over solution at best, though
almost certainly the one we'll have to go to in the near-to-medium
term.

Longer term, I think we need to start thinking more about programs and
their documentation as an *association* of some sort, the details of
which should be handled transparently to the user.

Some truly crude systems have used the executable itself as a way of
binding the associated data to the utility (and I guess ELF might be
good for this :-), e.g. storing the man page or source directory path
information somewhere in in the text segment, but that's just an
implementation issue.  I'm sure that a really fast (and robust)
system-wide registry database could eventually be evolved to support
multiple "views" of a given file tree, the executable nature of an
object being only one of potentially many properties.  Your `man'
command now also searches for the executable file or library (MANPATH
would be a superset of PATH).

Hmmmm.  I see Terry on the Cc list.  Might as well go for broke.. :-)

What would be really neat, mind you, would be to be able to view a
filesystem as a set of objects with property lists, sets of objects
being represented by "views" (which would, of course, themselves be
objects).  Using some sort of query API, you could create new view
objects to give your objects some illusion of an organizational model
(e.g.  the existing hierarchichal one or something even more
outlandish).  Sort of a poor man's relational database at the
filesystem level.

Then all the rest would be trivial, the implementation of which would
be left as an exercise to the reader. :-)

					Jordan