[tahoe-dev] [cap-talk] Sharing Tahoe file system directories?

[Jed Donnelley]

At 10:19 AM 5/2/2008, Norman Hardy wrote:
>On 2008 Apr 15, at 14:08 , Jed Donnelley wrote:
>
> > Why would I want a shallow read-only directory capability?  One
> > example
> > is to manage a project with other colleagues who I trust with write
> > access to some of the underlying objects.  I can manage the project by
> > choosing what to put into the shallow read-only directory (including
> > whether some of the pieces are writable, shallow read-only, or deep
> > read-only capabilities to directories) - nobody who I give it to can
> > modify it - but everybody who I give the shallow read-only capability
> > to can extract what's in it and write to that which I choose to share
> > write access.
>
>Keykos provides a RO key to a node (cap page).
>It was seldom used but there was at least one important use.
>Each yield of a particular factory would have a RO key to the node of
>holes for that factory.
>(See http://cap-lore.com/CapTheory/KK/Factory.html for factories and
>holes.)
>Had the yields had a write key to the node they would not have
>isolated from each other.
>A hole is a key found in that node which has been vetted to be trusted
>to be held and shared among yields of this factory.

I don't think I follow your reasoning/example above Norm.

I was trying to suggest to tahoe-dev that there is value in
"shallow" RO (what one usually refers to as simply RO) for
directories that make it helpful even if one has deep RO.  In
the above you seem to be arguing that there is a need for RO
(whether deep or shallow) as opposed to RW.  The Tahoe file
system has both RW and deep RO for directories.  I don't believe
there is any debate about needing both RW and deep-RO.  What the
tahoe file system doesn't have for directories is ordinary
(shallow) RO.  Do you believe shallow RO is needed?  If so, why?

Sorry if I'm missing the point you're making.

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