[cap-talk] MinorFS Philosophy

[Rob Meijer]

On Tue, July 15, 2008 02:24, Karp, Alan H wrote:
> Rob Meijer wrote:
>>
>> 2) * U asks M to delegate F.
>>    * M creates F in its own enviroment and delegates a read only
>>      capability to it to U, and keeps it in its controll for later
>> usage.
>>    * U (optionaly attenuated) re-delegates the received capability to
>> P.
>>    * P opens F and renders it.
>>
> Let me see if I understand.  The user has a right, such as the right to
> start a word processor application.  The user asks the application to
> create a new file, which the application does.  The application then
> delegates r/o authority to the user.  While the word processor is running,
> the user can save changes using the word processor's write authority.  At
> any time, the user can delegate the r/o authority to a rendering process
> for display.  Is that right?

The example was mailclient, but switching it for a word processor would be
ok. The only (essential difference being that the mailclient also would
maintain some mailbox internal database representation that it will not
delegate).

> Now to my problem.  The user closes the word processor application.  The
> user now re-opens the word processor application.  How does the user get
> r/o authority to the file?  What does the user do to edit the file?

I posted the folowing in a previous post, what I feel is essential here,
I hope I got the picture completely right:

  System  |    Entity      |  Persistence
----------+----------------+---------------
 Tahoe    |     user       |     yes
----------+----------------+---------------
 Plash/   |    process     |      no
 Capdesk  |                |
----------+----------------+---------------
 MinorFs  |    process     |     pseudo
----------+----------------+---------------
MinorFs + |                |
persistent|    process     |      yes
language  |                |
----------+----------------+---------------
 EROS/    |    process     |      yes
  etc     |                |
----------+----------------+---------------

Stopping and starting the process would in the ideal case where the word
processor or mail client and the second application would be written in a
(currently non existing) 'persistent' (ocap?) language mean absolutely
nothing when compared to the situation where the user would keep the
application open.

In the more realistic situation that it is just a written in a regular
language and (doesn't also serialize its own state to the available
private storage), the process will at least get the files back in its view
on MinorFs, and will be able to re-delegate it to the user if it wishes to
do so.

I feel the difference between (pseudo) persistent processes and non
persistent processes might be the most important difference here between
the Plash/Capdesk approach and the MinorFs approach to the problem.

If you look at it from this point, is it making more sense or not?

Rob