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.
bcn@june.cs.washington.edu (Clifford Neuman) (06/30/89)
I am presently working on a new way of organizing large distributed systems called the virtual system model. The motivating factor behind the virtual system model is that as systems get larger and larger it becomes harder to find things, and that a new way of organizing large systems is needed to address this problem. Although not specifically concerned with the user interface, the directory service I have implemented based on the virtual system model supports many of the features you indicate as desirable. Among these features are that the directory structure is a generalized directed graph instead of a tree. I call it 'generalized' because links in the graph can be of several types. A normal link is simply a pointer to a file or directory. A union link makes the contents of a linked directory appear as part of the present directory instead of as a subdirectory. Finally, a filter can be added to a link which can change the way one views the subtree to which the link was made. It can exclude certain objects, include objects that did not originally exist, or even change the name or other attributes of other objects. The key idea behind the virtual system model is to support customized views of the system. These views extend to other features of the system besides the file system. In a few days, I will send a more complete description of the model and what presently exists. The virtual system model is described in more detail in: B Clifford Neuman. "The Virtual System Model for Large Distributed Operating Systems". Technical report 89-01-07, Department of Computer Science, University of Washington, April 1989. Send a message with your US Mail address if you would like a copy of this report. ~ Cliff