Re: [FileAPI: Directories and System] Some comments

Thanks for the feedback, Peter--comments inline below.

On Sun, Jan 30, 2011 at 9:10 AM, Peta Byte <256petabyte@googlemail.com> wrote:
> 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.

Having the callbacks be global functions, rather than methods on the
object where the method was invoked, is pretty standard across all the
client-side storage APIs.  While I see the benefit of your suggestion,
I think the uniformity of the interface is more important.  We don't
want to surprise people who are using both the FileSystem and, say,
IndexedDatabase, by having inconsistent behavior.

> ## toURI-method of Entry Interface
> I'd recommend to spec out a common URI scheme for resources within a local
> filesystem, too.

Agreed.  What do you think of the URI scheme I proposed?
See http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0218.html

> 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.

I don't understand.  What "internal name" do you need?

> 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
>

Received on Monday, 31 January 2011 17:21:01 UTC