Re: Moving File API: Directories and System API to Note track?

Note: The {File,Directory}Entry types are also separately useful for
multi-file input and drag-n-drop applications:
http://wiki.whatwg.org/wiki/DragAndDropEntries

To summarize, it solves several problems with FileList:

1-  A DirectoryEntry can be lazily resolved by the developer.  With
FileList, the browser has to fully traverse a potentially deep directory
structure before it can provide the application with the FileList.  That
can be very slow.  DirectoryEntry enables applications to provide progress
UI.

2-  FileList is not good at representing empty directories.  Empty
directories can be important for cases where a user wishes to upload a
directory structure to a server.

(This has been implemented in Chrome for a little while now.)

My understand of the sysapps working group was that it was for APIs that
are not generally suitable for use in the conventional web sandbox.  They
are for use in a different ("system apps") sandbox.  What I've described
above is useful in both, and so standardizing in webapps seems to make
sense.

Regards,
-Darin


On Tue, Sep 18, 2012 at 4:11 AM, Robin Berjon <robin@w3.org> wrote:

> On 18/09/2012 13:04 , Olli Pettay wrote:
>
>> I think we should discuss about moving File API: Directories and
>> System API from Recommendation track to Note. Mainly because the API
>> hasn't been widely accepted nor implemented and also because there
>> are other proposals which handle the same use cases. The problem with
>> keeping the API in recommendation track is that people outside
>> standardization world think that the API is the one which all the
>> browsers will implement and as of now that doesn't seem likely.
>>
>
> I wonder if a good case couldn't be made to move it to the upcoming
> SysApps WG (http://www.w3.org/2012/05/**sysapps-wg-charter.html<http://www.w3.org/2012/05/sysapps-wg-charter.html>
> )?
>
> It's very late to sneak anything into the charter, but I reckon it could
> fall under their Media Storage API deliverable.
>
> --
> Robin Berjon - http://berjon.com/ - @robinberjon
>
>