username,usernumber,directoryname,directorynumber

[TEITELMAN]

Mail-from: Arpanet host BBN-TENEXD rcvd at 10-MAY-79 0813-PDT
Date: 10 May 1979 1106-EDT
Sender: LEWIS at BBN-TENEXD
Subject: y
Subject: [YONKE at BBN-TENEXD: directory names]
From: LEWIS at BBN-TENEXD
To: teitelman at MAXC2
Message-ID: <[BBN-TENEXD]10-May-79 11:06:01.LEWIS>

Warren,
here is the description of the direcotry fns.

Daryle
	
Begin forwarded message
Mail from BBN-TENEXD rcvd at 12-Feb-79 1344-EST
Date: 12 Feb 1979 1344-EST
From: YONKE at BBN-TENEXD
To: Teitelman at MAXC2, Masinter at MAXC2, Kaplan at MAXC2, lewis, 
    hartley
Cc: vittal
Subject: directory names
Message-ID: <[BBN-TENEXD]12-Feb-79 13:44:05.YONKE>
Sender: YONKE at BBN-TENEXD
[Text]: 
Note by YONKE on 12 Feb 1979 1324-EST 

Below is a proposal for changing the way directory names and numbers are
talked about in interlisp.  This was brought on by a major change in
TOPS20 in release 3.  Daryle has volunteered to implement the functions
maintaining TENEX/TOPS20 compatibility.  Comments/uproars/suggestions
are heartily welcome.  /mdy

============================================================

Release 3 of TOPS20 contains a major change in the way one "talks" about
directories.  First, what is thought of on TENEX as a USERNAME/NUMBER
has been split into two catagories:

        1.  A USERNAME is something you login or attach to (and that
            is all!).  A USERNUMBER isn't good for much (except when
            used in conjunction with certain system tables) and can
            only be guarenteed to remain consistent with a
            particular USERNAME during a system's up-time (i.e.,
            they may change when a system is brought up).  A
            USERNAME has the same format (essentially) as a TENEX
            USERNAME (i.e., a string of characters not enclosed in
            <>s).

        2.  There are two new entities called DIRECTORYNAME and
            DIRECTORYNUMBER.  These are essentially what one thinks
            of as USERNAME/NUMBER on TENEX and are what one uses to
            talk about directories and files.  A DIRECTORYNAME has
            the format "structure:<directoryname>" where structure:
            can be thought of as a "device" in TENEX mode, but is a
            way of partitioning the disk (so there can be mountable
            structures that don't clutter up the disk space most of
            the time).  When you ask for a DIRECTORYNAME from TOPS20
            you'll always get back one of these -- including the
            structure:  and <>s.  A DIRECTORYNUMBER should be
            thought of as very temporary (akin to a JFN) and remains
            consistent with a particular DIRECTORYNAME only for the
            lifetime of the program that got the DIRECTORYNUMBER and
            only for that program (i.e., you can't pass
            DIRECTORYNUMBERs between programs).
 
            Both DIRECTORYNUMBER and USERNUMBER are full 36 bit
            quantites and are never the same number.

Obviously, this change has a major impact on a single TENEX/TOPS20
INTERLISP.  (At a minimum, almost all calls to the current function
USERNUMBER should add T as the second parameter so that on TOPS20 you'll
get the more useful DIRECTORYNUMBER back -- of course this implies a box
on TOPS20 since you'll get back a full 36 bit number.)  I'd like to
propose some new functions (and change the use of some old functions) to
"hide" the differences between between the two systems.  To help keep
things straight in this discussion, whenever I refer to a current system
function (and its current use) I'll precede it by the string "old"
(e.g., the current USERNUMBER will appear as oldUSERNUMBER in the text).

Essentially, the proposal is rename the functions oldUSERNAME and
oldUSERNUMBER to DIRECTORYNAME and DIRECTORYNUMBER respectively (details
of all new functions will appear below).  These are the functions to use
when dealing with the file system.  The functions USERNAME and
USERNUMBER should then only be used to identify a user (not a
directory).  To alleviate calls to DIRECTORYNUMBER (i.e., oldUSERNUMBER)
and USERNUMBER which become expensive on TOPS20 there should be two new
functions:  DIRECTORYNAMEP and USERNAMEP which determine if what they
are given legitimate directory or user names -- I believe this was the
major use of oldUSERNUMBER used in conjunction with oldUSERNAME.  Also,
DIRECTORYNAME and USERNAME have been expanded to take directory and user
names (with escapes) as opposed to the oldUSERNAME which only took T,
NIL, or a number.  And finally, there should be a new system function
CNDIR which should be used for connecting to another directory inside of
Lisp (connecting to a directory on TOPS20 is (will be) radically
different implementation wise).

The documentation for the proposed functions follows.  The parameter
names DIRNAME and USERNAME can either be a litatom or string.


DIRECTORYNAME[DIRNAME;STRPTR]

        -  Returns a "full directory name" for DIRNAME.  If
           DIRNAME=NIL then return the login directory.  If DIRNAME=T
           then return the connected directory.  If DIRNAME is a
           string or litatom with an $ (escape) on the end then name
           completion will be attempted; if unsuccessful NIL will be
           returned.  DIRNAME can also be a number, in which case if
           DIRNAME is a valid directory number return its
           corresponding directory name.  Normally the directory name
           is returned as a string.  If STRPTR is a string pointer
           then it is smashed with the new string pointer.  If
           STRPTR=T then the directory name is returned as an atom.

DIRECTORYNAMEP[DIRNAME]

        -  Returns T if DIRNAME is a legitimate directory name.  If
           DIRNAME ends with an $ (escape) then name completion is
           attempted and T returned if successful, otherwise NIL.
           This function is provided for efficency so the
           DIRECTORYNAME string doesn't have to be created.

DIRECTORYNUMBER[DIRNAME]

        -  Returns the directory number for DIRNAME.  DIRNAME may end
           with an $ (escape) in which case name completition is
           attempted.  if DIRNAME=NIL then login directory number is
           returned.  If DIRNAME=T then the connected directory is
           returned.

USERNAME[USERNAME;STRPTR]

        -  Returns a user name for USERNAME.  If USERNAME=NIL then
           return the login user.  If USERNAME is a string or litatom
           with an $ (escape) on the end then name completion will be
           attempted; if unsuccessful NIL will be returned.  USERNAME
           can also be a number, in which case if USERNAME is a user
           number return its user name.  Normally the user name is
           returned as a string.  If STRPTR is a string pointer then
           it is smashed with the new string pointer.  If STRPTR=T
           then the user name is returned as an atom.  Note:
           USERNAME=T is meaningless (by the old interpretation, this
           would mean something like "connected login user") and will
           simply return NIL.

USERNAMEP[USERNAME]

        -  Returns T if USERNAME is a legitimate user name.  If
           USERNAME ends with an $ (escape) then name completion is
           attempted and T returned if successful, otherwise NIL.

USERNUMBER[USERNAME]

        -  Returns the user number for USERNAME.  USERNAME may end
           with an $ (escape) in which case name completition is
           attempted.  if USERNAME=NIL then login user number is
           returned.

CNDIR[DIRNAME;PASSWORD;-]

        -  Tries to connect to DIRNAME and if successful returns a
           full directory name (as an atom) for DIRNAME otherwise it
           returns NIL.  If PASSWORD (a string or litatom) is
           supplied it is used to aid in the connecting process.  The
           third parameter (FLG) is only used on TOPS20 and is used
           to specify different ways to "connect" (more will be said
           about this in another message for those interested).

Interactions with PACKFILENAME, UNPACKFILENAME, and FILENAMEFIELD:

Since structure:  looks exactly like DEVICE, UNPACKFILENAME works fine
as is.  PACKFILENAME on TOPS20 would have to check for a structure being
on the "front" of a directory name.  If it is there and there is no
DEVICE specified then PACKFILENAME works essentially like it does now.
If a device is specified separately and there is one in the directory
name, I propose whichever occurs first be the one used (this is similiar
to the way BODY is used).  I would also like to propose that STRUCTURE
become a synonym for DEVICE.  PACKFILENAME and FILENAMEFIELD would
accept either on both TENEX and TOPS20.  UNPACKFILENAME would return
with either the field being called DEVICE or STRUCTURE based on which
type of system Lisp is running on.

Impact on the system and user code:

In system code all calls to USERNUMBER should be looked at to determine
if it was being used in conjunction with USERNAME to get a legitimate
and complete USERNAME.  If so, these should be consolidated to one call
to DIRECTORYNAME.  (I did a MAPATOMS and found the only compiled
functions which call USERNUMBER are FILEINFOBLOCK, SPELLFILE, and
DIRECTORY.  FILEINFOBLOCK when dealing with changing the author field in
the FDB seems to be the only one which needs the new USERNUMBER.)  All
calls to USERNAME which exist after the previous alteration should just
be renamed to DIRECTORYNAME (again, the only calls to USERNAME are in
the functions FILEINFOBLOCK, GREETBLOCK, SETINITIALS, and WRITEFILE and
non-functions such as AFTERSYSOUTFORMS).  Since the parameters are
compatable, this should be easy.  Some files in LISPUSERS will also
certainly be effected (especially EXEC), but the changes are similiar.

Old user code running on TENEX should notice no difference since
USERNAME and USERNUMBER work the same for them.  They should however be
advised of the new directory functions and to use them instead.  Old
user code running on TOPS20 will have to be modified similiarly to the
system code, but since they were going to have to add the second
parameter to oldUSERNUMBER when they got Release 3 of TOPS20 anyway this
doesn't seem like a burden.

          --------------------
End forwarded message
		


-------