[cap-talk] Opening files in graphical shells (was: [e-lang] File API taming)

Sam Mason sam at samason.me.uk
Fri Mar 20 15:30:58 EDT 2009

 [ cap-talk cc'd as it's replying to a message that went there
 originally, cap-talk may be a more appropriate forum for further
 discussions ]

On Fri, Mar 20, 2009 at 12:11:26AM -0400, Kevin Reid wrote:
> I wrote a bit about the problem of mapping these inter-file  
> relationships into a capability filesystem, in the specific case of  
> HTML, in the following message to cap-talk.
> http://www.eros-os.org/pipermail/cap-talk/2009-February/012227.html
> -----------------------------------------------------------------------
> Suppose I have a Cap Desktop with a cap filesystem. In this filesystem
> I store a HTML document and the items linked or embedded: images,
> stylesheets, other pages...
> How does that document refer to the other items? In web language, what
> is the base URL for its relative URLs? How does the web browser
> acquire the appropriate file-caps?
> It is obviously inappropriate in a capability environment for the
> document to get access to a containing directory, and the web browser
> may not even have that access.
> My conclusion is that the file object which stores the HTML text also
> has a component which is a directory of the other file-caps which this
> document may refer to. That is, the file object is like
> {
>     content:     '...<img src="foo.gif">...',
>     local_names: {
>       "foo.gif": <cap to image file>,
>     },
> }
> (This is essentially the same as a closure: "content" is the
> "program", and "local_names" is the closed-over bindings, and all the
> relative URLs become "lambda names" as MarkM would say. There is no
> encapsulation, unless we define some universal-to-our-platform
> interpretation of HTML to use.)

This would appear to generalize well in the context of a user's
shell--I'm mainly thinking about graphical shells, although I see no
reason why it wouldn't work in text based shells as well.

I'd start by defining a "Bundle" as the name to capability map as above,
the difference is that it doesn't get directly associated with any
particular file.  Double clicking on a file (or otherwise indicating
than an action wants to be performed) would search for all bundles
that are associated with the file, if only one was found the name of
the selected file and the bundle would be passed to the program as it
starts.  Opening a file without exactly one associated bundle would
implicitly create a bundle with only one entry pointing to the indicated
file.  Saving files would implicitly define new bundles.

A few more examples:

  Makefiles; bundle would expand to the makefile's parent directory.

  My .bin/.hdr example up thread[1]; bundle would contain both files and
  double clicking on either would allow the file to open.

  HTML development; bundle would identify the HTML file's parent
  directory, allowing easier development by not requiring all resources
  to be explicitly identified.  It seems reasonable to also allow
  the parent of the file's parent directory to be chosen in larger
  development projects.

  Email client; double clicking on an attachment could create a bundle
  containing all attachments and open the indicated attachment.  I don't
  think this should be default but could be very useful.

Single clicking on a file would display any bundles associated with
it and if only one was found the designations would be visually
distinguished from those not included, if more than one bundle was found
it would have to be selected first.  It seems to simplify various other
operations; deleting a file with only one bundle could ask if all files
associated with the bundle be removed, similar seems to apply to copy

I can't decide whether bundles can be enumerated; I'd assume not, but
if a directory was the target of a binding the directory could be

  Sam  http://samason.me.uk/
 [1] http://www.eros-os.org/pipermail/e-lang/2009-March/013042.html

More information about the cap-talk mailing list