[cap-talk] MinorFS Philosophy

Rob Meijer capibara at xs4all.nl
Wed Jul 30 23:15:52 CDT 2008


On Wed, July 30, 2008 18:11, Karp, Alan H wrote:
> Rob Meijer wrote:
>>
>> I think what Alice "sees" can be divided into two, what Editor0 shows
>> her
>> and what Shell0 shows her. Initialy resume.txt would be only available
>> in
>> the Editor0 scope, so only Editor0 would be able to show Alice the
>> existence of resume.txt . Alice could ask Editor0 to delegate (full?)
>> access to the resume.txt file to Shell0 as a way to simulate the
>> user-global scope.
>>
> If each editor instance is used to edit exactly one file, then Editor0
> *is* resume.txt as far as Alice is concerned.  If each editor instance is
> used to edit many files, then Alice may end up mixing files with different
> protection needs in a single process, a problem we decided to document but
> otherwise ignore in Polaris.  As with Polaris, Alice can have different
> editor instances for different sets of files, but then she has to remember
> which editor instance to use for each file.

The 'first free slot' approach MinorViewFs takes might be indeed very
inconvenient here. There are two currently two ways to get around this.
The config allows to add either the commandline or named enviroment
variables to the identity of all Editor processes. The Editor0 "is"
resume.txt would fit the commandline approach. Adding a petname enviroment
variable to the Editor config and startup settings might allow the second
scenario.

>>
>> If you take the Shell0 scope to be the (user perceived) 'user-global'
>> scope, the amount of node's available and the extend of the authority
>> carried by these node's would be greatly reduced, making both the
>> margin
>> for user error smaller and the ability of the user to maintain a mental
>> overview of the tree graph better. Both these I feel would thus help to
>> have Alice use POLA on herself, what just as with POLA for any active
>> object should be beneficial IMO.
>>
> I think this description is confusing "permission" and "authority".  The
> capabilities in Alices's Shell0 scope are the permissions she has.  The
> set of rights reachable from those capabilities constitutes her authority.
>  Accessing the permission to use Editor0 in Shell0 grants authority
> identical to that of having the appropriate permission to resume.txt in
> Shell0.
>
> I'm not convinced about the mental model advantage, either.  Alice must
> ask Editor0 to show her which files it edits.  That's equivalent to
> traveling to an Editor0 directory in a file system, but with less
> flexibility on how files are organized.

The flexability would be partialy regained by delegation and composition
in the Shell0 scope.

There are IMO 2 major diferences between traveling to an Editor0 directory
in a filesystem and permitting Editor0 to use data hiding mechanism's on
its 'private' storage:

* Editor has knowledge of what type of files it uses for what purposes and
can express this in the user interface.
* You could view Editor as being a class and non delegated permisions as
private instance member data. Data hiding would I feel make the user's
life simpler just as it makes a programers life simpler not to have to
make all
her variables global ones.

Rob




More information about the cap-talk mailing list