[cap-talk] How desirable / feasible is a persistent OCAP language?

[Rob Meijer]

On Fri, July 25, 2008 10:18, Rob Meijer wrote:
> On Fri, July 25, 2008 04:59, Sandro Magi wrote:
>> Except the registry is also far less user friendly to view and manage
>> than something filesystem based. Persistent data is only as good as the
>> tools you have to manage it.
>>
>> Sandro
>
> I feel that comparing the registry with /etc/* is a false comparison.
> Given the registry actually implies both /etc/* and /var/*, and in order
> to be comparable.
>
> I feel /etc is better than registry while /var/ may be worse
> in many cases. The reason for this is the mutability scope of data stored
> in these. Limiting the scope of mutability is IMO essential for POLA.
>
> To me this means we should strive to make the granularity of 'private'
> mutable storage as fine grained as possible.
>
> Rob

I've been spending some more thoughts on the above, and thinking on how
to address the /var versus /etc issues.

Let me try to put some of my thoughts down:

/etc holds state that is to be changed only as act of administration,
normal running processes need and get no write access to it. The state is
mostly only relevant to the specific application, and is so for ALL
running instances of this application. The right granularity for such data
would be thus that it would be accessible only to instances of the given
application,
or in some cases a small group of applications, but in this later case,
the permission to the data could still be given to a single application
that delegates it to the others in the group.

/var holds state that is created and/or mutated by instances of an
application, we can view these instances as pseudo persistent processes
and say that the type of data stored in /var should actually be held
private to pseudo persistent processes.

$HOME/.$someapname holds both /var and /etc type data for a specific user,
for /var type data the same argument goes here that it should be held
private to pseudo persistent processes, given that a new incarnation of
such a process would run with thew same userid anyhow.

The /etc usage of $HOME/.$SOMEAP however should be made so that it is read
only available only to all instances of the specific application run by
the specific user.

Currently MinorViewFs holds a home link that is partialy meant to replace
the user global $HOME/.$SOMEAP, but as I now realize only for /var style
usage.

If I would change MinorViewFs accordingly (I need to finnish an
attenuation FS before I can do so)  , a process would get the folowing
private symlinks into MinorCapFs and MinorAttnFs:

  * home -> pseudo persistent process private mutable data
  * tmp  -> non persistent mutable data, deleted when the non persistent
            process ends.
  * etc  -> read only data available to all instances of the program
            run by the same user as the current instance.
  * root -> as etc, but program run by any user.

With respect to administration, home and etc would be user administrated,
while root would not.

I don't think I will add the 'root' link anytime soon given the scope of
MinorFs, but the 'etc' link would seem rather useful.

With respect to databases, using MinorViewFs 'home', (and if the above is
a good idea, 'etc' and possibly  'root') to hold sqlite databases for
configuration and serialization might not be a bad idea.

Rob