[cap-talk] Drag & "Attenuated" Drop?

[Rob Meijer]

On Wed, December 10, 2008 03:39, Kevin Reid wrote:
> On Dec 9, 2008, at 17:13, Rob Meijer wrote:
>
>> The thing I had in mind would look something like
>> http://polacanthus.net/DragNDrop.jpg at drop time.
>
>
> Brr. We need to do better than that, or nobody will want to use it.
> There are far too many independent, abstractly-expressed options there.

Ok, the 'abstractly expressed' part is something that needs to be and can
be fixed. The 'to many' part would be quite a challenge.

How MinorFs works in this is that a simple userspace filesystem provides
for unatenuated sparse caps to files and directories, thus a sub dir could
be delegated without exposing access to the parent dir, but without
attenuation of read and write.

Now a second userspace filesystem allows for the creation of a caretaker
style controll + attenuated node pair that are bound to the original node
with a petname. What basically would hapen as a result of the shown
interface would be:

* A caretaker-set node is created with given petname bound to the
  directory (or file) we want to delegate.
* The not checked bits are revoked on the caretker-set.
* The caretaker-set its attenuated node is delegated.
* Optional the control node is delegated to a user session bound process
  that revokes all remaining bits on user session end.

The 6 bits that can be revoked are the shallow attenuation r+w bits for
the designated file or directory, and if a directory is delegated, the
deep attenuation r+w bits for sub directories at any level and the deep
attenuation r+w bits for leaf files at any level.

If 'manual' revocation would be asked for, the user might go back to the
original directory node, trough the petname arrive at the caretaker-set
control node and revoke all or some of the remaining bits.

I would very much like to see if what would be really happening could be
transformed into terminology more in sync with the way most users tend
to abstract delegation, but am not sure if taking away 'to many' options
would be possible without dangerously presumptuous compromises on
flexibility of the underlaying system and/or the users intentions.

The shown dialog would be an almost one on one representation, I agree at
least the terminology needs to change somewhat. I am really struggling
with the concept of retaining the possibility of expressing user
intentions within the roams of system possibilities while still making the
interface less overwhelming.

> Attenuation is certainly important, but it has to be -- and to appear
> -- usable.

Agreed, and quite a challenge it seems to be to get there.

Rob