[_CDCSL_93-16_]<1>Cedar>release>Profiles>ProfilesDoc.tioga

ProfilesDoc.tioga

Eric Nickell, April 4, 1988 1:29:20 pm PDT

Dave Rumph, August 6, 1988 1:29:38 pm PDT

A GENERAL CUSTOMIZATION PACKAGE FOR CEDAR

CEDAR 7.0 —

Profiles

A General Customization Package for Cedar

Eric Nickell

Abstract: Profiles provides similar functionality to UserProfile, but allows a client to select a profile on a basis other than the current user or the current machine. It also can understand Cedar expressions as entries, and can enumerate entries.

Created by: Eric Nickell

Maintained by: Eric <Nickell.pasa>

Keywords: Profile

XEROX Xerox Corporation
Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, California 94304

1. Differences from UserProfile

Extensions

1) There may be more than one ``profile'', used by different clients or for different purposes. Thus, a Profile can be created given a set of files.

2) Profiles can understand some Cedar expressions. It is possible to request that a profile entry be used to fill the contents of some REF, or that a new REF of some particular type be created and filled from a profile entry. This feature can be disabled, removing the dependency on the Abstract Machine and Interpreter, by installing SimpleProfiles, rather than Profiles.

3) It is possible to enumerate profile entries whose keys match some pattern.

Limitations

1) Profiles does not support any sort of GuestProcs.

2) The client must decide between keeping a Profile fresh (that is, reflecting the contents of the files from which it was created), in which case the client becomes responsible for notifying Profiles when it is no longer interested in the Profile, OR allowing a Profile to become stale, in which case Profiles need not retain a copy of the Profile, and garbage collection will work properly when the client drops the Profile on the floor. The reason for this is that keeping the Profile fresh means that the implementation must hold a copy of the Profile, which means that (without heroic measures) garbage collection will not function properly.

Implementation differences

1) Profiles keeps its symbol table in a SymTab.Ref rather than a LIST.

2) In order to keep the Interpreter happy, commas (",") are no longer treated as white space, but become parts of tokens.

2. Profile Entries

The entries in a profile file are of the form <key>: <value>RETURN, where key is a sequence of alphanumerics or .'s (case does not matter) and value is either (1) a BOOLEAN, (2) an INT, (3) a TOKEN, which is a rope consisting of either a sequence of characters delimited by SP, CR, TAB, Comma, Colon, or SemiColon, or, in the case that the first character is '", the sequence of characters up to the next matching '", (4) a ListOfTokens, or (5) a Cedar expression. Comments can appear at any point in the profile, and are ignored.

Fine point: There is a mechanism to layer profiles. Entries of the form Include: <filename>RETURN acts as if the contents of the named file were included at this point. To make this feature more useful, a ">" (or "<") may be placed immediately after the colon of profile entries, meaning to append (or prepend) the <value> of this line to the previously defined <value> for the same key, if there is one.

3. Notes

It ought to take a fairly small effort, if desired, to layer UserProfile over Profiles. These questions would have to be addressed:

1) Should the GuestProc capability be moved to Profiles or remain in UserProfile?

2) Should the Cedar expression capabilities be extended to UserProfile? Do they conflict with remote GuestProcs?