[cap-talk] (no subject)

Rob Meijer capibara at xs4all.nl
Sun Aug 21 04:50:01 PDT 2011


I'm about to start creating a new version of MinorFs in Python (the
existing MinorFs was written in Perl).

Now my first priority is trying to make a new version of MinorFs to
facilitate applications like web browsers that want to offer distinct
private encapsulated storage to distinct RIAs. Secundary priority to
facilitate applications like Bitcoin in helping protect things like purses
safe from malware running as the normal user. Tertiary priority, not
braking things for non compiled languages like scripting languages and
languages running in a virtual machine.

In the existing MinorFs, pseudo-persistent-processes are the atomic level
of granularity to what private file-system storage is delegated. I
probably need to drop the pseudo persistent process as atom of granularity
and replace it with something more practical. This would mean I'll end up
with a less pure model, but what good is a purer model if nobody uses it
:-(

I'm having a hard time figuring out a useful granularity level for a new
MinorFs. The old approach 'program is a class, pseudo-persistent-process
is an object' made a lot of sense and made for a pure capability model,
but was rather impractical from a main stream programming point of view.

The following URL describes how the current MinorFs implementation
determines the mapping from a Linuc process ID to a pseudo persistent
process id.

http://minorfs.polacanthus.net/wiki/Pseudo_persistent_process

So I probably need to drop the pseudo persistent process as atom of
granularity and replace it with something more practical and with a lower
granularity level usefull for web browser builders and application
builders of stuff like bitcoin.

But what do I need to drop and what do I need to keep from the current set
of parameters that I use as atom of granularity?

Any ideas on this would be very much appreciated.



More information about the cap-talk mailing list