Glenn Maynard wrote:
I'm interested in the same from Mozilla side: what are the real issues
that you think are unsolvable, or do you just think the underlying use
cases aren't compelling enough for the work required?
Speaking for myself, not for all Mozillans here, I find the use-cases
Eric
-Original Message-
From: Olli Pettay [mailto:olli.pet...@helsinki.fi]
Sent: Thursday, October 04, 2012 3:48 AM
To: SULLIVAN, BRYAN L
Cc: Maciej Stachowiak; Glenn Maynard; Eric U; public-webapps@w3.org
Subject: Re: Moving File API: Directories and System API to Note track?
On 09/26
Asking about use cases that can be served by a filesystem API, but not
by IDB, is reasonable [and I'll respond to it below], but it misses a
lot of the point. The users I've talked to like the FS API because
it's a simple interface that everyone already understands, that's
powerful enough to
Maciej Stachowiak wrote:
On Sep 22, 2012, at 9:35 PM, Maciej Stachowiakm...@apple.com wrote:
On Sep 22, 2012, at 8:18 PM, Brendan Eichbren...@mozilla.com wrote:
And two of the interfaces are generic and reusable in other contexts.
Nice, and DOMRequest predates yours -- should it be done
On Tue, 25 Sep 2012, Brendan Eich wrote:
Maciej Stachowiak wrote:
On Sep 22, 2012, at 9:35 PM, Maciej Stachowiakm...@apple.com wrote:
On Sep 22, 2012, at 8:18 PM, Brendan Eichbren...@mozilla.com wrote:
And two of the interfaces are generic and reusable in other contexts.
Nice, and
On Sep 25, 2012, at 10:20 AM, James Graham jgra...@opera.com wrote:
In addition, this would be the fourth storage API that we have tried to
introduce to the platform in 5 years (localStorage, WebSQL, IndexedDB being
the other three), and the fifth in total. Of the four APIs excluding this
Hi Glenn,
I read over your points. But I don't think they would change Apple's
calculation about exposing an API to the real user filesystem in Safari,
particularly as specified. I do think that my more minimal API might also be a
better fit for the real filesystem use case, as it removes a
On Sat, Sep 22, 2012 at 8:32 AM, Eric U er...@google.com wrote:
While I don't see any other browsers showing interest in implementing
the FileSystem API as currently specced,
Just for the record, Blackberry, Tizen/EFL and Netfront seem to have some
support of FileSystem API.
EFL has also
On Sep 22, 2012, at 9:35 PM, Maciej Stachowiak m...@apple.com wrote:
On Sep 22, 2012, at 8:18 PM, Brendan Eich bren...@mozilla.com wrote:
And two of the interfaces are generic and reusable in other contexts.
Nice, and DOMRequest predates yours -- should it be done separately since (I
What does getMetadata a synchronously return?
I think this API as written is still a fair bit more complex than needed for
the sandboxed storage use case. It does seem simpler than Filesystem API.
Regards,
Maciej
On Sep 21, 2012, at 10:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri,
On Sep 21, 2012, at 10:10 PM, Jonas Sicking jo...@sicking.cc wrote:
For what it's worth, I put together a draft for what an API would look
like that has basically the same feature set as the current FileSystem
API, but based on DeviceStorage. It's a much smaller API that the
current
Maciej Stachowiak wrote:
On Sep 21, 2012, at 10:10 PM, Jonas Sickingjo...@sicking.cc wrote:
For what it's worth, I put together a draft for what an API would look
like that has basically the same feature set as the current FileSystem
API, but based on DeviceStorage. It's a much smaller API
On Sep 22, 2012, at 8:18 PM, Brendan Eich bren...@mozilla.com wrote:
And two of the interfaces are generic and reusable in other contexts.
Nice, and DOMRequest predates yours -- should it be done separately since (I
believe) it is being used by other proposals unrelated to
On 09/20/2012 11:45 PM, Darin Fisher wrote:
File path information is already exposed via input type=file multiple.
File names may contain partial paths.
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#concept-input-type-file-selected
I couldn't
No comment on the value of DirectoryEntry for enabling asynchronous listing
of files in input type=file multiple?
-Darin
On Thu, Sep 20, 2012 at 4:48 PM, Maciej Stachowiak m...@apple.com wrote:
+1
I don't see an indication of any major browser but Chrome planning to
implement this and
On Fri, Sep 21, 2012 at 1:14 AM, James Graham jgra...@opera.com wrote:
On 09/20/2012 11:45 PM, Darin Fisher wrote:
File path information is already exposed via input type=file multiple.
File names may contain partial paths.
http://www.whatwg.org/specs/**web-apps/current-work/**
Or.. drag-n-drop receipt of a folder or set of folders.
On Fri, Sep 21, 2012 at 3:50 PM, Darin Fisher da...@chromium.org wrote:
No comment on the value of DirectoryEntry for enabling asynchronous
listing of files in input type=file multiple?
-Darin
On Thu, Sep 20, 2012 at 4:48 PM, Maciej
While I don't see any other browsers showing interest in implementing
the FileSystem API as currently specced, I do see Firefox coming
around to the belief that a filesystem-style API is a good thing,
hence their DeviceStorage API. Rather than scrap the API that we've
put 2 years of discussion
I like the idea of offering asynchronous listing of files in input type=file
multiple. But I think Filesystem API is overkill for this use case.
Regards,
Maciej
On Sep 21, 2012, at 3:50 PM, Darin Fisher da...@chromium.org wrote:
No comment on the value of DirectoryEntry for enabling
My personal objections (ones that I think are shared by at least some other
Safari folks):
- It's way too complicated. (As one crude metric, I count 22 interfaces; and
yes, I know many of those are callback interfaces or sync versions of
interfaces; it still seems overengineered).
- I see
On Fri, Sep 21, 2012 at 5:37 PM, Maciej Stachowiak m...@apple.com wrote:
My personal objections (ones that I think are shared by at least some other
Safari folks):
- It's way too complicated. (As one crude metric, I count 22 interfaces; and
yes, I know many of those are callback interfaces
On Wed, 19 Sep 2012, Adam Barth wrote:
On Wed, Sep 19, 2012 at 1:46 PM, James Graham jgra...@opera.com wrote:
On Wed, 19 Sep 2012, Edward O'Connor wrote:
Olli wrote:
I think we should discuss about moving File API: Directories and
System API from Recommendation track to Note.
Sounds good
On Wed, Sep 19, 2012 at 11:50 PM, James Graham jgra...@opera.com wrote:
On Wed, 19 Sep 2012, Adam Barth wrote:
On Wed, Sep 19, 2012 at 1:46 PM, James Graham jgra...@opera.com wrote:
On Wed, 19 Sep 2012, Edward O'Connor wrote:
Olli wrote:
I think we should discuss about moving File API:
On Wed, Sep 19, 2012 at 11:50 PM, James Graham jgra...@opera.com wrote:
On Wed, 19 Sep 2012, Adam Barth wrote:
On Wed, Sep 19, 2012 at 1:46 PM, James Graham jgra...@opera.com wrote:
On Wed, 19 Sep 2012, Edward O'Connor wrote:
Olli wrote:
I think we should discuss about moving File
+1
I don't see an indication of any major browser but Chrome planning to implement
this and expose it to the Web.
- Maciej
On Sep 18, 2012, at 4:04 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
Hi all,
I think we should discuss about moving File API: Directories and System API
from
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,
On Wed, 19 Sep 2012, Edward O'Connor wrote:
Hi,
Olli wrote:
I think we should discuss about moving File API: Directories and
System API from Recommendation track to Note.
Sounds good to me.
Indeed. We are not enthusiastic about implementing an API that has to
traverse directory trees
On Wed, Sep 19, 2012 at 1:46 PM, James Graham jgra...@opera.com wrote:
On Wed, 19 Sep 2012, Edward O'Connor wrote:
Olli wrote:
I think we should discuss about moving File API: Directories and
System API from Recommendation track to Note.
Sounds good to me.
Indeed. We are not enthusiastic
28 matches
Mail list logo
