Design issue: Virtualized filesystem

I've just written up a couple of design issues on the wiki:
http://wiki.erights.org/wiki/Virtualized_privileged_environment
http://wiki.erights.org/wiki/Opaque_file_objects

I would particularly like comment on the latter, because it is a  
specific major change to the file object protocols. The text follows.

-----------------------------------------------------------------------
Problem
-------

     1.  See Virtualized privileged environment.

     2.  In general, a program should not be unnecessarily aware of the
         non-capability environment around it, in particular absolute
         paths in the filesystem.

     3.  We would like E to be compatible with actually interacting with
          a capability filesystem.

Furthermore, we want to accomplish this while still using java.io.File  
objects in E-on-Java.

Proposal
--------

Currently,
     * the file__uriGetter is uniquely the root of the filesystem and  
has
       a distinct interface.

     * every File object reveals its absolute pathname.

Instead,
     * Every directory is equally usable as a root;
       file__uriGetter == <file:///>

     * File objects cannot be asked for their pathnames; instead,
       <file:///a>.optUnget(<file:///a/b/c>) returns "/b/c"
       (or possibly "b/c"), much as a SturdyRef can only be converted to
       a cap-URL using <captp>.

XXX Write up exactly what the File interface would become.

XXX Write up and crosslink the "file: should use true URI syntax  
including %xx" issue.

------------------------------------------------------------------------

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>