[cap-talk] MinorFS Philosophy

[Rob Meijer]

On Tue, July 15, 2008 06:03, Rob Meijer wrote:
> 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  |                |

Forgot about Polaris here, sorry Alan.


> ----------+----------------+---------------
>  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.

Looks like my brain wasn't sufficiently booted up at 6 in the morning to
produce coherent English sentences.

Let me try to state it again a bit more coherent set of sentences:

There are basically theoretically 5 ways to use the private storage
provided by MinorFs:

1) As a location where, if someone was to write a 'persistent' ocap
   language, the process 'image' could be stored in a location only
   accessible to the process that is to be the new incarnation of the
   persistent process.
2) A location where a program written in a language with serialization
   support can put serialized parts of itself as a way to simulate 1.
3) A private location for processes to store 'private' file system data
   (dirs and files).
4) Delegation of (decomposed,attenuated etc) access to 3.
5) Making the receiving end of 4 persistent (composition).

If a process is stopped and started again, and doesn't implement 1 or 2,
at least all files and directories created in 3, or persistently linked
in 5, will again be available to the new 'incarnation' of the process.

> 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


Rob