std-mumps@gang.plus5.UUCP (01/02/85)
From: Hokey (The Moderator) <std-mumps-request@plus5.UUCP> Ansi MUMPS digest Tuesday, 1 Jan 1985 Volume 1 : Issue 8 Today's topics: Expanded naming in Mumps ---------------------------------------------------------------------- Date: Sat Dec 29 21:11 CST 1984 From: hokey@plus5.UUCP Subject: Expanded naming in Mumps [This is a slightly edited version of a mail message which I sent to Richard Walters, PhD. He is a member of the task group which is trying to deal with the issue of networking and expanded "namespaces" for the MDC. Hokey] The basic idea behind my naming proposal is outlined in two articles which appear in the MUG Quarterly Special Issue 1981, Vol XI, No. 2/3, and the Winter 9182-83, Vol XII, No. 4. To summarize, the proposal attempts a *logical* naming convention which incorporates "files" (routines, text, and any others) within a heirarchy of package/program names (arbitrarily deep). A package resides in a directory on a particular system. There are defaults. At the "lowest" level, the existing Mumps environment exists (for example, the routine DI). A package/program list may be specified, limiting the namespace (for example, <FileMan>DI). A test version could exist in a different directory (<Test:FileMan>DI). Duplicate names (in different packages) are handled "intelligently". A possible grammar follows: filespec = lhs rhs | rhs lhs = <did:sid:pid> | <did:sid:> | <did:pid> | <did:> | <:sid:pid> | <:sid:> | <pid> rhs = fid:ext:rev | :ext:rev did = directory id sid = system id pid = package/program id fid = file id (a routine, or anything else) ext = extension rev = revision number did, sid, and pid references can have subfields. The subfields are separated by dots (.). The "primary" (first . piece) of the sid is optional. This provides a way to reference information on "this" system. Relative directory references are very useful. At the moment, I suspect we could treat a null primary did (.a, for example) as being relative to the current directory. I have not thought a lot about this issue. It is very important to note that this mechanism describes a logical, as opposed to a physical, naming convention. This approach makes no assumptions about the implementation of networked systems. We will probably have to change the definition of "sid" to deal with "bushy" networks. I would like to see a mechanism for both implicit and explicit "naming" of routines, globals, lock namespaces, and "lhs" stuff. We might consider a new command to specify the default or implicit "name", or use a new special variable. I think we must permit multiple packages to exist in a directory. This means that, to use an instant possible syntax, the File Manager global DD in "this" directory, ^<FileMan>DD, is *not* the same as, say a Costar global of the same name in the same directory (^<Costar>DD). The same holds true for the namespaces defined by the LOCK command. This means that it will be easy to integrate arbitrary "packages" of software which each want to use LOCKs, something which we *cannot* do at all under the existing standard. Granted, the inclusion of incremental locks will provide a mechanism for maintaining locks if a sub{package,routine} wishes to use them, but this is only true if name collisions have been resolved. I would also like to stress that a package/program identification is *not* the same as a directory specification. By keeping the two entities distinct, we greatly ease the issue of software updates (installation of a package of software is independent of the directory in which it resides), as well as maintenance (different "versions" of a package can be kept in different directories, again without changing the pid). Hokey ------------------------------ End of Ansi MUMPS digest ************************ -- Hokey ..ihnp4!plus5!hokey 314-725-9492