[cap-talk] Reducing the authority of a file browser in a capability OS.

[David-Sarah Hopwood]

Rob Meijer wrote:
> On Wed, December 23, 2009 00:03, David-Sarah Hopwood wrote:
>> Rob Meijer wrote:
>>> If the system has some way to restart the instance that created the
>>> file (a pseudo persistent process), than this instance would have
>>> persistent access to the files it created.
>>
>> Why should it? If we're just talking about document files, then that's
>> excess authority.
> 
> The alternative seems to be placing the unattenuated file into the global
> namespace prematurely without the user's explicit request to do so,
> cluttering up the namespace that this user needs to administer.

The file gets put into the user's namespace when the user saves it under
a particular name. If the user closes the app instance, they get a prompt
to save the file and if they cancel that, the file is discarded. I don't
see a problem here; it works just as users would expect from existing
operating systems, except that there is isolation between app instances.

If you mean recovery from a autosaved version, that does not require the
instance used for recovery to be a persistent reincarnation of the original
instance. In fact we don't want it to be, because that instance crashed
and its overall state just before the crash must be assumed to have been
corrupt. Only the autosaved file should be passed to the new instance,
not all files that the old instance created.

> In my view the 'least' authority is when the authority resides with the
> creator pseudo persistent process until the user 'explicitly' asks for a
> (revocable, optionally attenuated) cap to delegate to an other process.
> In contrast forcing the user to 'prematurely' put the file into a global
> namespace just for the sake of making the powerbox all powerful seems to
> me what constitutes excess. For me the ideal user interface would allow me
> to ask one pseudo persistent process for an icon representing a revocable
> capability that could than be drag-dropped to a second process OR pseudo
> persistent process without the intervention of a file chooser type
> powerbox at each end forcing the user to use and clutter this global
> namespace that the powerbox is made responsible of.

Drag and drop is a separate issue. The file doesn't need to be in a global
namespace in order to be dragged-and-dropped; why would it?

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20091223/9880e8d0/attachment.bin