I'd like to bring back up the discussion that went on at [1] and [2].
In particular, I'd like to propose a minimal set of restrictions for
file names and paths, punt on the issue of what happens in later
layers of the API, and discuss case-sensitivity rules.
For the sandboxed filesystem, I
I've grouped responses to bits of this thread so far below:
Glenn said:
If *this API's* concept of filenames is case-insensitive, then IMAGE.JPG
and image.jpg represent the same file on English systems and two different
files on Turkish systems, which is an interop problem.
Timeless replied:
On Wed, May 11, 2011 at 4:47 PM, timeless timel...@gmail.com wrote:
On Thu, May 12, 2011 at 2:08 AM, Eric U er...@google.com wrote:
Timeless replied:
no, if the api is case insensitive, then it's case insensitive
*everywhere*, both on Turkish and on English systems. Things could
only be case
On Wed, May 11, 2011 at 4:52 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, May 11, 2011 at 7:08 PM, Eric U er...@google.com wrote:
*everywhere*, both on Turkish and on English systems. Things could
only be case sensitive when serialized to a real file system outside
of the API. I'm
On Wed, May 11, 2011 at 7:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wednesday, May 11, 2011, Eric U er...@google.com wrote:
I've grouped responses to bits of this thread so far below:
Glenn said:
If *this API's* concept of filenames is case-insensitive, then IMAGE.JPG
and image.jpg
On Tue, May 17, 2011 at 2:41 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, May 17, 2011 at 2:35 PM, Kyle Huey m...@kylehuey.com wrote:
The abort behaviors of FileReader and File[Saver|Writer] differ. The
writing objects throw if the abort method is called when a write is not
currently
It was likely just an oversight on my part that they differ.
It does seem a bit odd to dispatch error/abort/loadend if aborting
with no write in progress, so I favor the FileWriter/FileSaver
behavior, but as long as they match, I'm not too bothered.
On Tue, May 17, 2011 at 2:35 PM, Kyle Huey
On Tue, May 17, 2011 at 2:48 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, May 17, 2011 at 2:42 PM, Eric U er...@google.com wrote:
It was likely just an oversight on my part that they differ.
It does seem a bit odd to dispatch error/abort/loadend if aborting
with no write in progress, so I
On Thu, May 12, 2011 at 1:34 AM, timeless timel...@gmail.com wrote:
On Thu, May 12, 2011 at 3:02 AM, Eric U er...@google.com wrote:
There are a few things going on here:
yes
1) Does the filesystem preserve case? If it's case-sensitive, then
yes. If it's case-insensitive, then maybe.
2
The optional mimeType parameter to Entry[Sync].toURL is redundant with
url.createObjectURL. It also doesn't work with the URL format
proposed in the notes and now implemented in Chromium. I have removed
it from the spec.
Eric
Sorry about the very slow response; I've been on leave, and am now
catching up on my email.
On Wed, Jun 22, 2011 at 11:54 AM, Arun Ranganathan a...@mozilla.com wrote:
Greetings Adam,
Ian, I wish I knew that earlier when I originally posted the idea,
there was lots of discussion and good ideas
On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan a...@mozilla.com wrote:
On 5/23/11 6:14 PM, Arun Ranganathan wrote:
On 5/23/11 1:20 PM, Kyle Huey wrote:
To close the loop a bit here, Firefox 6 will make the change to
FileReader.abort()'s throwing behavior agreed upon here.
On Tue, Sep 20, 2011 at 3:36 PM, Eric U er...@google.com wrote:
On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan a...@mozilla.com wrote:
On 5/23/11 6:14 PM, Arun Ranganathan wrote:
On 5/23/11 1:20 PM, Kyle Huey wrote:
To close the loop a bit here, Firefox 6 will make the change
On Tue, Sep 20, 2011 at 4:43 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Sep 20, 2011 at 4:28 PM, Eric U er...@google.com wrote:
On Tue, Sep 20, 2011 at 3:36 PM, Eric U er...@google.com wrote:
On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan a...@mozilla.com wrote:
On 5/23/11 6:14 PM
On Tue, Sep 20, 2011 at 5:32 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Sep 20, 2011 at 5:26 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Sep 20, 2011 at 8:01 PM, Eric U er...@google.com wrote:
I have a read running, and at some point I abort it--it could be in
onprogress
On Wed, Sep 21, 2011 at 2:28 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Sep 21, 2011 at 11:12 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Sep 20, 2011 at 8:40 PM, Eric U er...@google.com wrote:
Indeed--however, from a quick skim of XHR and XHR2, that's not what
they do. They let
On Wed, Sep 21, 2011 at 3:09 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Sep 21, 2011 at 5:44 PM, Eric U er...@google.com wrote:
If we want the file specs to match the XHR spec, then we can just
leave this as it is in File Reader, and I'll match it in File Writer.
Recursion depth limit
On Wed, Sep 21, 2011 at 3:29 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Sep 21, 2011 at 6:14 PM, Eric U er...@google.com wrote:
If we eliminate it entirely, then you can't ever start a new read on
the same object from the abort handler. That seems like a reasonable
use case.
It's
Thanks Glenn and Simon--I'll see what I can do.
On Fri, Sep 23, 2011 at 1:34 AM, Simon Pieters sim...@opera.com wrote:
On Fri, 23 Sep 2011 01:40:44 +0200, Glenn Maynard gl...@zewt.org wrote:
BlobBuilder.append(text) says:
Appends the supplied text to the current contents of the
On Thu, Sep 22, 2011 at 4:47 PM, Glenn Maynard gl...@zewt.org wrote:
native Newlines must be transformed to the default line-ending
representation of the underlying host filesystem. For example, if the
underlying filesystem is FAT32, newlines would be transformed into \r\n
pairs as the text
On Mon, Sep 26, 2011 at 2:38 PM, Arthur Barstow art.bars...@nokia.com wrote:
The upcoming TPAC meeting (Oct 31 - Nov 01) provides an opportunity for
joint WG meetings and lots of informal sharing. As such, some groups make
spec publications right before TPAC.
Note there is a 2-week
On Thu, Sep 29, 2011 at 12:22 PM, Arun Ranganathan a...@mozilla.com wrote:
On 9/21/11 8:07 PM, Eric U wrote:
Update: I have made the changes to FileWriter/FileSaver's event
sequences; they now match FileReader.
That's not to say it won't change pending discussion, but FileWriter
should
The exception is thrown by getFile on DirectoryEntrySync, not by the
Flags constructor; both the example and the flags interface are
correct.
On Sat, Oct 8, 2011 at 11:54 AM, Bronislav Klučka
bronislav.klu...@bauglir.com wrote:
Hello,
http://www.w3.org/TR/file-system-api/#the-flags-interface
On Mon, Oct 24, 2011 at 3:52 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi everyone,
It was pointed out to me on twitter that BlobBuilder can be replaced
with simply making Blob constructable. I.e. the following code:
var bb = new BlobBuilder();
bb.append(blob1);
bb.append(blob2);
On Wed, Oct 26, 2011 at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai o...@chromium.org wrote:
The new API is smaller and simpler. Less to implement and less for web
On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking jo...@sicking.cc wrote:
1. Make loadend not fire in case a new load is started from
onabort/onload/onerror.
On Fri, Oct 7, 2011 at 12:02 PM, Mark Pilgrim pilg...@google.com wrote:
What should this do?
requestFileSystem(2, 100, successCallback); // assume successCallback
is defined properly
requestFileSystem doesn't throw, so you should get an errorCallback
call. You haven't provided an
On Wed, Nov 2, 2011 at 3:56 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Nov 2, 2011 at 9:56 AM, Eric U er...@google.com wrote:
On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 3, 2011
On Tue, Nov 15, 2011 at 5:41 AM, Rich Tibbett ri...@opera.com wrote:
Jonas Sicking wrote:
Hi everyone,
It was pointed out to me on twitter that BlobBuilder can be replaced
with simply making Blob constructable. I.e. the following code:
var bb = new BlobBuilder();
bb.append(blob1);
Bronislav:
Thanks for the tip; it's already fixed in the latest editor's
draft, so the fix will get published the next time the document is.
See the latest at
http://dev.w3.org/2009/dap/file-system/file-dir-sys.html.
Eric
On Wed, Dec 21, 2011 at 12:21 AM, Bronislav Klučka
On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard ch...@visc.us wrote:
Modern operating systems have efficient mechanisms to send a signal when a
watched file or directory is modified.
File and FileEntry have a last modified date-- currently we must poll entries
to see if the modification
On Tue, Jan 10, 2012 at 1:08 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
We've been looking at implementing FileWriter and had a couple of questions.
First of all, what happens if multiple pages create a FileWriter for
the same FileEntry at the same time? Will both be able to write to
On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard ch...@jumis.com wrote:
On 1/11/2012 9:00 AM, Glenn Maynard wrote:
This isn't properly specced anywhere and may be impossible to implement
perfectly, but previous discussions indicated that Chrome, at least, wanted
File objects loaded from
On Wed, Jan 11, 2012 at 12:25 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Jan 10, 2012 at 1:32 PM, Eric U er...@google.com wrote:
On Tue, Jan 10, 2012 at 1:08 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
We've been looking at implementing FileWriter and had a couple of questions
On Tue, Dec 20, 2011 at 9:24 AM, Anne van Kesteren ann...@opera.com wrote:
Sorry for restarting this thread, but it seems we did not reach any
conclusions last time around.
On Thu, 03 Nov 2011 00:07:48 +0100, Eric U er...@google.com wrote:
I think I may have missed something important. XHR2
Thanks! I'll take care of those.
On Sat, Feb 25, 2012 at 5:02 AM, Ms2ger ms2...@gmail.com wrote:
Hi all,
There are a number of bugs in the WebIDL blocks in
http://dev.w3.org/2009/dap/file-system/file-writer.html.
* The 'in' token has been removed; void append (in Blob data); should
be
Yeah, the reason is that Arun's more on-the-ball than I am. I'll be
updating the spec quite soon, I hope.
On Mon, Feb 27, 2012 at 2:35 AM, Felix-Johannes Jendrusch
felix-johannes.jendru...@fokus.fraunhofer.de wrote:
Hi,
is there any reason why the File API: Writer and File API: Directories
Sorry about the slow response; I've been busy with dev work, and am
now getting back to spec work.
On Sat, Jan 21, 2012 at 9:57 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Jan 11, 2012 at 1:41 PM, Eric U er...@google.com wrote:
On Wed, Jan 11, 2012 at 12:25 PM, Jonas Sicking jo
What I can do is procrastinate until we agree that BlobBuilder is
deprecated, and this is now the problem of the Blob constructor. Over
to you, Arun and Jonas.
On Mon, Sep 26, 2011 at 11:45 AM, Eric U er...@google.com wrote:
Thanks Glenn and Simon--I'll see what I can do.
On Fri, Sep 23
On Sat, Feb 25, 2012 at 5:02 AM, Ms2ger ms2...@gmail.com wrote:
Hi all,
There are a number of bugs in the WebIDL blocks in
http://dev.w3.org/2009/dap/file-system/file-writer.html.
* The 'in' token has been removed; void append (in Blob data); should
be void append (Blob data);.
Fixed.
*
I like the Event Invariants writeup at the end. It's only
informative, but it is, indeed, informative.
However, I'm not sure it quite matches the normative text in one
respect. Where you say [8.5.6 step 4]: Terminate any steps while
processing a read method. Does that also terminate the steps
On Mon, Feb 27, 2012 at 4:40 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 27, 2012 at 11:36 PM, Eric U er...@google.com wrote:
One working subset would be:
* Keep createFileWriter async.
* Make it optionally exclusive [possibly by default]. If exclusive,
its length member
Incidentally, the way XHR gets around this is to have open cancel any
in-progress abort. We could certainly do the same thing, having any
readAs* cancel abort().
On Tue, Feb 28, 2012 at 4:15 PM, Eric U er...@google.com wrote:
I like the Event Invariants writeup at the end. It's only
On Wed, Feb 29, 2012 at 1:43 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
FileReader.abort is like a bad penny :)
However, I'm not sure it quite matches the normative text in one
respect. Where you say [8.5.6 step 4]: Terminate any steps while
processing a read method. Does that
On Wed, Feb 29, 2012 at 2:57 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
On Wed, Feb 29, 2012 at 1:43 PM, Arun Ranganathan
Otherwise, if you start a new read in onabort [8.5.6 step 5],
you'll
still deliver the loadend [8.5.6 step 6].
This contradicts 8.5.9.2.1 Once a loadstart
In the readAsText in the latest draft [1] I see that readyState gets
set to done When the blob has been read into memory fully.
I see that elsewhere in the progress notification description, When
the data from the blob has been completely read into memory, queue a
task to fire a progress event
On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
Eric,
In the readAsText in the latest draft [1] I see that readyState gets
set to done When the blob has been read into memory fully.
I see that elsewhere in the progress notification description, When
the data
On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 02 Mar 2012 01:01:55 +0100, Eric U er...@google.com wrote:
On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
OK, so the change is to ensure that these events are fired directly
On Thu, Mar 1, 2012 at 11:20 AM, Arun Ranganathan
aranganat...@mozilla.com wrote:
Eric,
So we could:
1. Say not to fire a loadend if onloadend or onabort
Do you mean if onload, onerror, or onabort...?
No, actually. I'm looking for the right sequence of steps that results in
abort's
On Mon, Mar 5, 2012 at 2:01 PM, Eric U er...@google.com wrote:
On Thu, Mar 1, 2012 at 11:20 AM, Arun Ranganathan
aranganat...@mozilla.com wrote:
Eric,
So we could:
1. Say not to fire a loadend if onloadend or onabort
Do you mean if onload, onerror, or onabort...?
No, actually. I'm
After a brief internal discussion, we like the idea over in Chrome-land.
Let's make sure that we carefully spec out the edge cases, though.
See below for some.
On Fri, Mar 2, 2012 at 4:54 PM, Feras Moussa fer...@microsoft.com wrote:
At TPAC we discussed the ability to deterministically close
On Wed, Mar 7, 2012 at 11:38 AM, Kenneth Russell k...@google.com wrote:
On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote:
You can always call close() yourself, but Blob.close() should use the
neuter
On Tue, Mar 6, 2012 at 5:12 PM, Feras Moussa fer...@microsoft.com wrote:
From: Arun Ranganathan [mailto:aranganat...@mozilla.com]
Sent: Tuesday, March 06, 2012 1:27 PM
To: Feras Moussa
Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson; Anne van Kesteren
Subject: Re: [FileAPI]
On Wed, Feb 29, 2012 at 8:44 AM, Eric U er...@google.com wrote:
On Mon, Feb 27, 2012 at 4:40 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 27, 2012 at 11:36 PM, Eric U er...@google.com wrote:
One working subset would be:
* Keep createFileWriter async.
* Make it optionally exclusive
On Fri, Mar 30, 2012 at 5:39 AM, Arthur Barstow art.bars...@nokia.com wrote:
Hi All - the publication of the File API LC was delayed because of some
logistical issues for Arun as well as some additional edits he intends to
make.
This delay also resulted in Eric's two File * specs not being
On Thu, Apr 12, 2012 at 12:54 PM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 12 Apr 2012 21:48:12 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
Because it's still in the current editor's draft and it's still in the
Gecko code and I was just reviewing a patch to it and saw the API? ;)
On Mon, Mar 19, 2012 at 3:55 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Feb 29, 2012 at 8:44 AM, Eric U er...@google.com wrote:
On Mon, Feb 27, 2012 at 4:40 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Feb 27, 2012 at 11:36 PM, Eric U er...@google.com wrote:
One working subset
According to the latest editor's draft [1], a File object must always
return an accurate lastModifiedDate if at all possible.
On getting, if user agents can make this information available, this
MUST return a new Date[HTML] object initialized to the last modified
date of the file; otherwise, this
On Wed, May 30, 2012 at 11:59 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/30/12 2:05 PM, Eric Uhrhane wrote:
How about session, which is guaranteed to go away when the browser
exits
Should it go away if the browser crashes (or is killed by an OOM killer or
the background process killer
Agreed.
On Wed, Jul 11, 2012 at 1:02 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
On May 23, 2012, at 9:58 AM, Glenn Maynard wrote:
On Wed, May 23, 2012 at 3:03 AM, Kinuko Yasuda kin...@chromium.org wrote:
Just to make sure, I assume 'the underlying storage' includes memory.
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
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
On Tue, Oct 30, 2012 at 1:04 PM, Brady Eidson beid...@apple.com wrote:
(Sending again as my first attempt seems to have not gone out to the list)
On Oct 30, 2012, at 12:10 PM, Kinuko Yasuda kin...@chromium.org wrote:
Reviving this thread as well... to give a chance to get more feedbacks
As discussed at TPAC, there's little support for the current FileSystem API, but
some support for a new API, and I promised to put forth a compromise proposal.
In order to do that, I'd like to hear 1) what kinds of changes would make it
more popular; 2) who I'm trying to convince. There are a
On Fri, Nov 30, 2012 at 9:11 AM, SULLIVAN, BRYAN L bs3...@att.com wrote:
-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Friday, November 30, 2012 6:46 AM
To: ext Eric U; Doug Schepers
Cc: Web Applications Working Group WG
Subject: Re: FileSystem
On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan a...@mozilla.com wrote:
At the recent TPAC for Working Groups held in San Jose, Adrian Bateman, Jonas
Sicking and I spent some time taking a look at how to remedy what the spec.
says today about Blob URLs, both from the perspective of default
On Wed, May 1, 2013 at 4:53 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 1, 2013 at 4:25 PM, Eric U er...@google.com wrote:
On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan a...@mozilla.com wrote:
Switching the default to false would enable IE, Chrome, andFirefox to
have
On Mon, May 6, 2013 at 5:03 AM, Glenn Maynard gl...@zewt.org wrote:
On Mon, May 6, 2013 at 6:27 AM, Robin Berjon ro...@w3.org wrote:
Another question to take into account here is whether this should only be
about zip. One of the limitations of zip archives is that they aren't
streamable.
On Wed, May 1, 2013 at 5:16 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, May 1, 2013 at 7:01 PM, Eric U er...@google.com wrote:
Hmm...now Glenn points out another problem: if you /never/ load the
image, for whatever reason, you can still leak it. How likely is that
in good code, though
OK, I just finished making my way through the public-script-coord
thread [I'm not on that list, but someone pointed me to it]. I have
no official objections to you editing a spec based on Jonas's
proposal, but I do have a couple of questions:
1) Why is this on public-script-coord instead of
Good writeup, Jonas--I think you've hit the major points.
I think numeric priorities are both overkill and underpowered,
depending upon their specific implementation. Without the promise
we're currently making for Persistent storage [this will never be
cleared unless you do it or the user
Status:
The specs are clearly dead; it's just been way down on my
priority list to do anything about it. We should funnel it off to be
a Note [or whatever the proper procedure is--Art?].
Eric
72 matches
Mail list logo
