Re: Fwd: When will we see a solid capability OS?
David Hopwood <david.hopwood-mRVxzIiVagSlV3Ge8JjJtnfLna9zW77MtUK59QYPAWc@public.gmane.org>
| Newsgroups | gmane.comp.lang.e.general |
|---|---|
| Message-ID | <[email protected]> |
David Hopwood wrote: > Constantine Plotnikov wrote: >> IMHO the most acute problem is a good application-level persistence >> model (unless I have missed some breakthrough here). Note I do not >> think that orthogonal persistence model is sustainable in the long run >> (more on that is here: >> http://constantine-plotnikov.blogspot.com/2007/02/software-system-longevity-paradigms.html). > > Support for persistent capabilities does not imply support for orthogonal > persistence. > > Persistent capabilities can be implemented in a filesystem-oriented > model, just by splitting each file into data and capability "forks" > (the latter acting as an array of capabilities), and adding primitives > to get or set the capabilities in a particular subrange of a designated > file's capability fork. Incidentally, this approach can be used to unify files and directories, allowing directories to be implemented entirely independently of the filesystem (whether or not the latter is in the kernel), possibly with multiple specialized implementations. (A minor complication here is that application writers normally expect resolving a path to be a prompt operation, which it isn't necessarily if you have to invoke a user-mode directory implementation. But it would be no bad thing for application writers to think of resolving a path as a blocking, potentially expensive operation, because it is already in the presence of network filesystems and symbolic links.) -- David Hopwood