On Tue, Jul 13, 2004 at 09:49:29AM +0900, Stephen J. Turnbull wrote:
> Of course P2P is _exactly_ what you describe (files residing on
> individual workstations being offered for share, with a central
> directory service), with the additional requirement that the directory
> service be transparently presented as a Unix filesystem.

Thinking about representing multiple data sets (volumes) in a Unix-like
directory tree - in Coda for the moment we have a design problem:

 - it is the realm administrator task to choose where volumes
   are connected==mounted together, thus building the realm file tree

 - volume creation is also purely the realm administrator task

 - still everyone can create mountpoints for whichever volumes

(it implies among other things that it is rather easy to confuse venus
on a client by creating mountpoints to other users' volumes and "hijacking"
the callbacks. it provides also multiple paths to the same data which
makes authorization enforcement less reliable, you cannot protect
a file tree by making its top protected, you have to know
that there are no mountpoints below that point...)

This situation is a bit controversial, so we should/could
 1. limit the possibility to create mountpoints for arbitrary volumes
    to system administrators
    (easy and should not disrupt anything)
    let the users manage mountpoints for volumes named after the pathnames,
    it is rather safe (we already have cfs mkm <name> without explicit volume
    name)

 2. possibly provide a framework for any user to be able (given rights)
    to manage space on servers == create/delete/modify/rename volumes
    (probably a can of worms :)
    limiting volume naming for a user to a path-like pattern according
    to the user's (home) directory would nicely isolate users from each
    other at least concerning the namespace, neither contradict the
    limitation above

I don't think [2] is of immediate interest, but [1] is.

As usual, my 2c,
--
Ivan