[FileAPI: Directories and System] Some comments

Hello everybody,

it's the first time I participate in a working group's mailinglist like
this, so when
my concerns rather belong to the implementation area (like the mailinglists
of browser developers) please correct me.


# Foreword:

I studied Eric Uhrhane's working draft of "File API: Directories and System"
[1] and wrote
some demo apps (including a multi-view File Manager that can extract tar
archives) using
the implementation that landed in recent releases of Chromium's Dev Channel.
Doing so I
noticed some aspects of the drafted API that could be improved.


# Suggestions

## Callback methods used in asynchronous filesystem interfaces

Nearly all registerable callbacks [2] are called being bound to the global
scope object,
instead to the object they were registered on (File-/Directory-/Entry,
DirectoryReader, asf.).
In my opinion this is unfavorable because in practice the async operation
one starts
(like querying metadata of an Entry or the contents of a directory) almost
always will
be handled in context of the entity the received information belongs to.

Only the extensive use of closures and/or additional logic that keeps track
of running
async operations (in order to "map" the response and trigger further events)
allows to
work around this behaviour. Sure, that might be the rationale for 3rd party
libaries, but
as a webdeveloper that strives for performant code (like most of us do)
I'd suggest to
to avoid this "overhead" and just spec out to which objects those callbacks
should
be bound to.


## toURI-method of Entry Interface

I'd recommend to spec out a common URI scheme for resources within a local
filesystem, too.
Some reasons for this:

    * Content of a permant filesystem should (theoretically) exist for a
longer period of time (read
      for more than one sessions)
    * Avoids that user agents mistakenly interpret the value of
href-attributes as local File URLs
      (though the file path begins with a slash)
    * When multiple filesystem instances are used within a session, a user
agent is able to identify the
      specific filesystem where the resource identified by a URL resides in.

In my demo file browser I introduced a pseudo URI scheme that looks like
this:

    `lfs://file__0:Persistent/a/b/c.txt`

Where the scheme "lfs" stands for "Local FileSystem" (as far as I know not
officially reserved;
only used internally by Cascading, a Java library to work with Hadoop FSs) .
As authority part
I simply used the value of the "name" attribute of the FileSystem interface.
Then I appended
the absolute filepath that every Entry has (fullPath attribute).

Bubbling Click events of HTMLAnchorElements are catched either by the code
of a custom
widget or -- finally -- at the HTMLBodyElement that asks the user how to
handle it or simply
suppresses it.

To dereference the URLs I created a wrapper go the LocalFileSystem/-Sync
interface that is
used to request filesystem instances. The name of every requested filesystem
is saved
together with a reference to the according FIleSystem in a lookup table and
used to resolve
the filesystem based on the authority part of a LFS-URI. Up to now, this is
a wacky solution
because there is no way to request a FileSystem by it's internal name. As
long as I only use
one persistent FileSystem this might work over more than one sessions. Of
course, no serious
solution.

This leads to my next suggestion:


## Extend LocalFileSystem/-Sync interface by method to request FileSystem by
its internal name

As outlined in the section above, a precondition for persistent URLs of
Local FileSystem resources
that can be dereferenced by 3rd party applications is a method that tries to
request a FileSystem
by its internal name/id.



Well, that's it. :-)

Would like to head what you think about my suggestions.


Best regards,

Peter






[1]
http://www.w3.org/TR/2010/WD-file-system-api-20101026/#idl-def-LocalFileSystem
[2] http://www.w3.org/TR/2010/WD-file-system-api-20101026/#callbacks