[tahoe-dev] Various objects and their capabilities (was: Re: [cap-talk] XML as capabilities.)

[Jed Donnelley]

At 10:27 PM 4/11/2008, John McCabe-Dansted wrote:
>On Sat, Apr 12, 2008 at 12:07 PM, John Carlson
><john.carlson3 at sbcglobal.net> wrote:
> > Okay, I'm familiar with using XML as capabilities.  I've done that
> >  myself.
> >  No one wants to try SQL as capabilities?  I'm game.  What else do we
> >  have to add to SQL to make them capabilities?
>
>Well SQL Views, Tables, and pre-compiled Queries are all objects that
>could be OO-caps just like any other.
>
>To use Tables and Views as caps where programmers expect to be able to
>just send random strings to the parser would require a bit of
>engineering, but this doesn't seem a big issue. Possibly we could
>create a string like object that allows caps to be embedded.
...

I agree that of course in principle something along the above
lines could be done.  Capabilities as data to "objects" like
tables and views and queries (one wonders where "object"
databases come into the picture).  I'm reminded a bit of the
testing I'm doing on Tahoe.  Hmmm.  I was going to post a
Tahoe capability (along the lines of the wideword capability
I posted previously), but perhaps I better get an OK
from the developers first.  There are some issues to be
worked out, but I'm quite positive about the basic Tahoe
file system concept.

Still, an important aspect of simply generating capabilities
as data for such "objects" is working out the semantics
of how capabilities flow in response to requests.  That is,
if I have, for example, a capability to a database table,
what capabilities can I fetch through it.  For Tahoe the
rules are quite simple for fetching through directories
(the only objects that capabilities can be fetched
through):

(from: http://allmydata.org/source/tahoe/trunk/docs/about.html )
______

There are two kinds of files: immutable and mutable. Immutable files 
have the property that once they have been uploaded to the storage 
grid they can't be modified. Mutable ones can be modified. A user can 
have read-write access to a mutable file or read-only access to it 
(or no access to it at all).

A user who has read-write access to a mutable file or directory can 
give another user read-write access to that file or directory, or 
read-only access to that file or directory. A user who has read-only 
access to a file or directory can give another user read-only access to it.

When linking a file or directory into a parent directory, you can use 
a read-write link or a read-only link. If you use a read-write link, 
then anyone who has read-write access to the parent directory can 
gain read-write access to the child, and anyone who has read-only 
access to the parent directory can gain read-only access to the 
child. If you use a read-only link, then anyone who has either 
read-write or read-only access to the parent directory can gain 
read-only access to the child.
_______

Pretty darn simple.  Their "read-only" is what I've previously referred
to as "deep read-only" - which I accept is the most important of the
two "read-only" 'types'.  If they get even the above working effectively
I think it will be a terrific system that, to use Jonathan's words:

(a) works, and (b) visibly solves a problem.

We may be a ways from (a) <despite its seeming simplicity> but we'll see.

The main reason I included all the above was to show how important
I think the semantics are of the model for fetching capabilities
from other capabilities.  The above Tahoe model creates a directed
graph with files and directories being fetched through directories.
The model for what you can fetch through a directory is supremely
simple:

If the directory is RO, you get whatever you fetch (file
or directory) as RO.  If the directory is RW, you get
whatever you fetch (whether RO or RW as in the directory).

It's that kind of simple power that I think needs to
be made available in capabilities (e.g. as data) to other
object types before they will "visibly solve a problem"
(with enough simplicity to make them usable).

I know the above Tahoe model (at least with the non
deep RO added and as I'm understanding it so far) visibly
solves a problem because I saw it work at LLNL for
some 25 years.

--Jed  http://www.webstart.com/jed-signature.html