<<>> GeneralPathsDiscussion.mail 30-Mar-90 Mike Spreitzer General Paths Date: Fri, 30 Mar 90 07:44:50 PST Sender: Mike Spreitzer:PARC:Xerox Subject: General Paths To: PCedarImplementors^:PARC:Xerox Cc: Mike Spreitzer:PARC:Xerox Well, we said we wanted to discuss them, right? So here goes. I have two points to make in this message: (1) why we don't want them, and (2) how we might do them. Using our DF software on a filesystem with attachments and caching gives finer control and better performance than using search paths, at a cost of writing explicit declarations (ie, DFs) that are a good thing anyway. Rather than working on a general path mechanism, let's worry about getting a filesystem with attachments and caching, and improve our language (DFs) for those explicit declarations. If we *do* introduce a general-purpose search-path mechanism, it should be very widely available. In particular, it should appear in the PFS interface, or alongside it, or be accessible through it. It should also become possible to say "short name X relative to path Y" wherever it is now possible to utter a filename. Both these desiderata are satisfied by making a kind of view that involves path searching. For example, we could say that -path:/Foo/Bar/baz.ext means to search along path Foo for the relative name Bar/baz.ext. [Digression: we could introduce another kind of view that means DF searching. It could cache the results of DF enumeration, and thus be as efficient as BringOver followed by file references. This also gets us a way to say "short name X relative to Y.DF" as a filename, which has been a good idea for a long time.] What should PFS.Open[PFS.PathFromRope["-path:/Foo/Bar/baz.ext"], create] mean? If we imagine that path Foo is serving a purpose analogous to a working directory into which some stuff has been BroughtOver, we could expect that the first directory in path Foo is a working directory in which all file creation relative to path Foo would take place. We could also imagine that some paths are used for purposes that do not include file creation; thus we might expect that each path consists of not only a list of directories but also a bit indicating whether creations happen in the first directory or not at all. What if the highest version of -path:/Foo/Bar/baz.ext is !3 before that Open call, but the directory containing !3 is not the first; does the file created in the first directory have version !4 ? Is that a problem? Who is responsible for determing which bit-and-list-of-directories (let's call that a `path value') is associated with the path identifier "Foo"? What is the scope of such a binding? The desired path varies from purpose to purpose (ie, from command lookup to .tip lookup to font lookup to ...), and sometimes even instance to instance (in DCedar, different command tools can have different command search paths). I think programs can be expected to know what their purpose is, but the variation from instance to instance comes from the desires of users (at least sometimes). Thus, we could expect that there is a fixed association, known to programs, between purposes and path identifiers, and that users are responsible for declaring which path value is to be bound to each path identifier. How can we let users varying the bindings (between path ID and path value) from instance to instance? The simplest way is to allow users to change the bindings at any time, and require that instances requiring different bindings occur during disjoint intervals of time (with a user action - the binding change - between them). This is just too crude for my taste. But if we're designing a general mechanism, we can use only general controls. The next most refined general mechanism that occurs to me is process properties. We could say that each process has its own set of bindings between path ID and path value (with suitable inheritence [we really *should* get FORK vs process props working right] and default mechanisms, to cut down the tedium). But this is still quite a blunt instrument --- but it's conceivable that I could be talked into accepting it. The next most refined mechanism that occurs to me is also the most refined, and looks like quite a lot of trouble too: reify the abstraction of "the set of bindings" in a data structure (maybe opaque) that is explicitly passed around. In this case, every tool that gives the user a way to initiate something must also carry around such a set of bindings (for at least the path IDs associated with the purposes that might be activated as a result of whatever the user initiates), and must also give the user some way to control that set. Another problem with this approach is that there's no room in the PFS interface (or FS, or TIPUser.InstantiateNewTIPTable, or ViewerTools.MakeNewTextViewer, or ...) to pass this additional parameter. Thoughts? Mike 30-Mar-90 Marvin Theimer Re: General Paths Date: Fri, 30 Mar 90 08:35:21 PST In-reply-to: "Mike Spreitzer:PARC:Xerox's message of Fri, 30 Mar 90 07:44:50 PST" Sender: Marvin Theimer:PARC:xerox Subject: Re: General Paths To: Mike Spreitzer:PARC:Xerox Cc: PCedarImplementors^:PARC:Xerox Reply-To: Marvin Theimer:PARC:xerox I have two questions/comments: If we explicitly specify things in DFs and we have a transparent, distributed file system then what are the fundamental reasons for wanting attachments? I can only think of two reasons for wanting attachments, both artifacts of "circumstance". The first reason is that our language tools don't all understand file names that contain a full pathname. I.e. they ASSUME that everything is in a single directory and act accordingly. The second reason is that NFS does no file caching and hence we have to do it manually at the application level. Since I view a clean, sparse, distributed file system interface to be a fundamental part of a well-designed distributed systems architecture, I'm leary of adding concepts such as attachments to the interface instead of fixing the "stupidities" of the applications using the file system. (Of course, there is the reality of using existing software...) Am I missing something about the notion of attachments? Consider also that the "bring it all over into a single directory" approach starts breaking down when you demand that the support tools and packages be brought over to ensure consistency. And we better bring over the rest of the system as well to ensure proper closure of the program object being created. This brings me to my second question. SRC has been thinking hard about system modeling and is a fair way towards a completed design/implementation. Has anyone looked at their work to see whether we can/should incorporate their design into ours? Marvin.