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

Rob Meijer capibara at xs4all.nl
Fri Mar 20 17:11:13 EDT 2009


On Fri, March 20, 2009 20:30, Sam Mason wrote:
>  [ 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
> operations.
>
> 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
> enumerated.
>

I would like to sugest a different approach based largely on my work on
MinorFs. In MinorFs there are two ways to access a file or directory:

1) Using a sparse cap for the file or directory.
2) Using a sparse cap for the parent directory together with a petname
   within the namespace defined for that parent directory.

I feel there is one provision (that MinorFs does not currently provide)
needed for making this setup work for things like html:

 "Drop the distinction between files and directories"

If you do this, the cap to the html file itself would define a namespace
for petnames to live in. If the webserver would be written to auto
redirect
requests for $parentcap/$petname to $nodecap, decomposition would be
automatic. This way the image in html file would work as follows:

1) The html file is accessed using https://hostname/$basecap/foo.html
2) The server redirects this to https://hostname/$foocap/
3) The html contains the code <img src="bar.jpg">
4) The client requests https://hostname/$foocap/bar.jpg
5) The server redirects to https://hostname/$barcap/
6) The jpeg file is returned.

Logically the jpeg file would be at the path :

  https://hostname/$basecap/foo.html/bar.jpg .

In this example if we lose the difference between directory and file,
'foo.html' would be on a filesystem where it is both. Thus foo.html would
be accessible as the html file, but would also be the directory containing
bar.jpg. There would be no need to put spare caps in the html file as long
as the base hierarchy is followed down the hierarchy.

I feel the most important property of a capability style filesystem is
that '..' in any access granting form should be considered evil. The
directory treegraph needs to be unidirectional. It seem to me that losing
the distinction between file and directory would be very beneficial to
this concept when used in combination with html.

Rob



More information about the cap-talk mailing list