Date: Wed, 05 Jun 1996 17:02:02 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> 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 Message-ID: <28584.834019322@time.cdrom.com> In-Reply-To: Your message of "Wed, 05 Jun 1996 14:34:57 PDT." <Pine.AUX.3.91.960605142028.18110A-100000@covina.lightside.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?28584.834019322>