abbott@aerospace.aero.org (Russell J. Abbott) (06/29/89)
The current focus of the Aerospace Computer Aided System Engineering & Integration (CASEI) project is on developing a new, user-friendly front end to computing environments. Our immediate goal is to build a prototype substitute for Unix shells on Suns and the Finder on Mac II's. I'm not sure that this is the place to discuss it, but I'd like to start a discussion of the kinds of things one would want in a up-to-date front end. The following provides an example of the sorts of things we are thinking of. In general, the new front end will be visual (like the Mac) and "object oriented." When one logs on, one's directory/folder structure will be displayed as a tree in a window. (Actually it will be an arbitrary directed graph. There is no requirement that it actually be tree structured.) Each node of the graph corresponds to one directory/folder. The name of the node, i.e., the directory/folder name, will be displayed, but files/objects stored at a node will not be. When a node is clicked, a sub-window will pop up displaying the contents of that node. The directory/folder graph will actually include all directories/folders in the system, and perhaps on the available(?) network. One can examine the entire file system (permissions permitting) by traversing the graph. Some of the leaves may be "intensional directories." An intensional directory is a directory whose contents are specified by an expression rather than by a set of pointers. (A Unix path expression e.g., ~/abc/de*fg, is a simple example of a expression that may be used to define intensional directories.) The range of possible expressions is yet to be defined. Most likely it will never be fully defined since there is no reason to prevent users from writing their own interpreters for directory expressions. One intended use of intensional directories is to allow a more flexible structuring mechanism for one's files. For example, when doing software development one may want a single directory to contain source code, object code, and documentation for a module. Yet, one may also want a single directory or directory structure that contains all the documentation for an entire system. Intensional directories facilitate this by letting one build multiple structures over a base structure -- more or less as one does with "views" in database systems. Another reason we are interested in intensional directories is that we want to build a service through which users can find out about programs, tools, models, etc. in their environment. It is not clear exactly what sort of information retrieval or database service will eventually be built, but whatever the service is, it will presumably have a query language. Expressions in that language will be acceptable as intensional directory expressions. We'd appreciate any comments, suggestions, or recommendations of other work to examine. Russ Abbott & Nick Lubofsky abbott@aerospace.aero.org lubofsky@aerospace.aero.org P.S. We have also started a mailing/discussion list of potential users of the system. To get on the list, write to: abbott@aerospace.aero.org. To send a message to the entire list, write to: casei@ses.aero.org.
rcpieter@eutrc4.urc.tue.nl (Pieter Schoenmakers) (06/30/89)
In article <53645@aerospace.AERO.ORG> abbott@aero.UUCP, Russell J. Abbott writes: >The directory/folder graph will actually include all directories/folders >in the system, and perhaps on the available(?) network. One can examine >the entire file system (permissions permitting) by traversing the graph. Is this workable? I can imagine a computer hooked onto a network with lots of fileservers. I can't imagine the graph to be useful then, - taking extremely much display space or - needing a window with a very large extent, taking ages to traverse. - taking ages to build (all directories must be known). - needing lots of management (newly created directories must be reflected in the graph). >Some of the leaves may be "intensional directories." An intensional >directory is a directory whose contents are specified by an expression >rather than by a set of pointers. (A Unix path expression e.g., >~/abc/de*fg, is a simple example of a expression that may be used to >define intensional directories.) The range of possible expressions is >yet to be defined. Most likely it will never be fully defined since >there is no reason to prevent users from writing their own interpreters >for directory expressions. > >One intended use of intensional directories is to allow a more flexible >structuring mechanism for one's files. For example, when doing software >development one may want a single directory to contain source code, >object code, and documentation for a module. Yet, one may also want a >single directory or directory structure that contains all the >documentation for an entire system. Intensional directories facilitate >this by letting one build multiple structures over a base structure -- >more or less as one does with "views" in database systems. You should design these expressions carefully, since regular expressions just won't do, and you probably don't want users just to define a list of files that must be held in the directory. How do you solve the problem of saving a file in an intensional directory, while the files does not match the intensional directory's 'selecting' expression? How about using UNIX' links? And what if a user deletes a file in an intentional directory, and sees it vanishing in the 'real' directory? Not very consistent (though the same problem occurs when using the UNIX links). On the ADFS, a filing system used by the Acorn Archimedes, files don't have extensions, and the '.' is directory seperator. This implies a C source file to be called c.foo, which is the file 'foo' in the directory 'c'. Similar for other directories like h, s and o. This scheme ensures a very neat directory structure of a s/w project, your intention with intensional directories. ---Tiggr
lubofsky@aerospace.aero.org (Nick Lubofsky) (07/01/89)
In article <769@eutrc3.urc.tue.nl> rcpieter@eutrc4.UUCP (Pieter Schoenmakers) writes: >Is this workable? I can imagine a computer hooked onto a network with lots >of fileservers. I can't imagine the graph to be useful then, > - taking extremely much display space or > - needing a window with a very large extent, taking ages to traverse. > - taking ages to build (all directories must be known). > - needing lots of management (newly created directories must be reflected > in the graph). It could be a window with a very large extent, but theoretically it wouldn't take long to go to any desired point because one could invoke some kind of a search command and go close to the desired directory and then browse through files related by certain aspects (the precise aspects you are searching for) quickly. Meanwhile, unbeknownst to the user, the computer only needs to build what is visible at any given time in the window. This will be quick. >You should design these expressions carefully, since regular expressions >just won't do, and you probably don't want users just to define a list of >files that must be held in the directory. The list itself wouldn't be stored, the query would be stored. I agree regular expressions aren't very useful. A true ad hoc query would be ideal. > How do you solve the problem of saving a file in an intensional directory, >while the files does not match the intensional directory's 'selecting' >expression? Since only the query is stored, the next time it is requested it does an up-to-date listing of files matching the description. >How about using UNIX' links? We are intending to replace UNIX. ____________________________________________________________________________ Nicholas Lubofsky | lubofsky@aerospace.aero.org | The Aerospace (213) 336-5454 | {decvax,ihnp4}trwrb!aero!lubofsky | Corporation VoiceMailbox 3064 | Life is precious, Love is so rare... | Los Angeles ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lubofsky@aerospace.aero.org (Nick Lubofsky) (07/05/89)
This is more on the CASEI project described by Russ Abbott in a
previous article.
CASEI (Computer-Aided Software Engineering and Integration) may not be
the best name for what we're doing here. I prefer to call the project
Front End.
I envision Front End as a tool that is sitting on a computer when an
arbitrary person walks up to it. I want it to be attractive, obvious,
and easy to use so that people that are afraid of computers can walk
up to it and use it (like the computer interfaces they have at some
malls.) This is seriously lacking in operating systems I have seen.
However, an advanced computer user should be able to walk up to the
Front End and quickly get to where he wants to. Often a person is in
the middle of one or more sessions of programming environments. They
should be able to get right back into them. This part already exists
in operating systems.
Front End should have both. Also, both the beginning and the advanced
user should have an interface for finding something. This is what Russ
Abbott was talking about. Systems are cluttered with arbitrary folders
and directories sprawling about in arbitrary ways. A higher level of
organization would save some frustration.
An ideal scenario would be: A person with no prior knowledge of
computers needs to see a diagram or picture of something, say a
blueprint of a truck or airplane. He should be able to walk up to a
terminal, and using Front End with no outside help, either locate the
specific diagram, or perhaps find out that such a picture doesn't
exist on that system. He should easily be able to browse through
related things on the system, and find out about related things on
other systems.
Currently, we have begun creating a prototype in Smalltalk. I am not
convinced that Smalltalk is the best environment to develop in, but it
is somewhat portable system to system. Does anyone have any ideas on
that?
By the way, does anyone know if the name "Front End" is being used for
any piece of software?
____________________________________________________________________________
Nicholas Lubofsky | lubofsky@aerospace.aero.org | The Aerospace
(213) 336-5454 | {decvax,ihnp4}trwrb!aero!lubofsky | Corporation
VoiceMailbox 3064 | Life is precious, Love is so rare... | Los Angeles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~