Opaque file objects

From Erights

Revision as of 01:57, 9 February 2011 by Kevin Reid (Talk)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

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.

Personal tools
more tools