[cap-talk] MinorFS Philosophy

Rob Meijer capibara at xs4all.nl
Wed Jul 30 01:50:06 CDT 2008

On Tue, July 29, 2008 19:18, Karp, Alan H wrote:
> Rob Meijer wrote:
>> The editor does thus not have to ask a powerbox for a part of the
>> static
>> global home treegraph to be delegated to it, instead it can store the
>> resume.txt in its own private home storage space, and delegate the
>> resume
>> file to the user, or any program that it can communicate with.
>> The receiving program also has its own private home storage, that it
>> can
>> use to create a symlink to the delegated resume.txt file, in order to
>> also
>> make the delegation persistent.
> Good example.  Thanks.  Now I want to understand the advantages of what
> you propose.
> Alice "sees" something called resume.txt in her view of the file system,
> which is really a symlink to a cap.  When she activates it, the system
> restarts Editor0, which has in its environment the cap to the actual data
> file.

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.

Alternatively however, Alice could choose to consider not to pollute the
persistent part of the Shell0 scope with non essential authority, and when
Alice wishes MailClient0 to have (revocable?, read only ?) access to
resume.txt, Alice could ask Editor0 to delegate (revocable/read only ?)
access to the resume.txt file to MailClient0.

> If that's right, the only thing Alice can do with what she sees as
> resume.txt is open it with instance Editor0, which seems pretty limiting.
> If that's wrong, I don't understand the benefit of putting the file under
> Editor0 instead of under Alice, since she can do anything with the symlink
> she could do with a reference to the file itself.

If we change the example so the editor would not create resume.txt, but
resume.xml (where resume.xml holds typesetting information in an xml
format not widely used by other editors), it may be a bit more clear.
If Alice, using Editor0 created resume.xml, Alice would normally not ever
wish any other process to have access to resume.xml. Alice would thus not
need to ask Editor0 to delegate it to either Shell0 or any other program,
and putting resume.xml into any (simulated or real) user-global scope
would pollute that scope with unneeded authority that the user would need
to manage. To understand what I mean, just do a 'find ~' to see how
polluted such a user-global scope can be with files that are normally
accessed by only one program. Instead the Editor0 could have a
functionality to export and or synchronize a pdf version of the document
'resume.pdf', and on export delegate a read only attenuation to this file
to Shell0.

This would thus mean that Alice could edit her resume, synchronize the pdf
file, and have the updated read only attenuated version available from
Shell0. Resulting in the situation where she could re-delegate it
(optionally revocable) to MailClient0 from Shell0.

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.

(Side Note: attenuation and revocation as described above are not yet
ready in MinorFs)


More information about the cap-talk mailing list