Re: [whatwg] File API Streaming Blobs

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 wrote: > Greetings Adam, > >> Ian, I wish I knew that earlier when I originally posted the idea, >> there was lots of discussion and good ideas but then i

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan 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. > (https://bugzilla.mozilla

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Tue, Sep 20, 2011 at 3:36 PM, Eric U wrote: > On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan 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

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Tue, Sep 20, 2011 at 4:43 PM, Jonas Sicking wrote: > On Tue, Sep 20, 2011 at 4:28 PM, Eric U wrote: >> On Tue, Sep 20, 2011 at 3:36 PM, Eric U wrote: >>> On Mon, May 23, 2011 at 6:19 PM, Arun Ranganathan wrote: >>>> On 5/23/11 6:14 PM, Arun Ranganathan wrote

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Tue, Sep 20, 2011 at 5:32 PM, Jonas Sicking wrote: > On Tue, Sep 20, 2011 at 5:26 PM, Glenn Maynard wrote: >> On Tue, Sep 20, 2011 at 8:01 PM, Eric U wrote: >>> >>> I have a read running, and at some point I abort it--it could be in >>> onprogress or el

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Wed, Sep 21, 2011 at 2:28 PM, Jonas Sicking wrote: > On Wed, Sep 21, 2011 at 11:12 AM, Glenn Maynard wrote: >> On Tue, Sep 20, 2011 at 8:40 PM, Eric U wrote: >>> >>> Indeed--however, from a quick skim of XHR and XHR2, that's not what >>> they do.  T

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Wed, Sep 21, 2011 at 3:09 PM, Glenn Maynard wrote: > On Wed, Sep 21, 2011 at 5:44 PM, Eric U 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 de

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Wed, Sep 21, 2011 at 3:29 PM, Glenn Maynard wrote: > On Wed, Sep 21, 2011 at 6:14 PM, Eric U 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 ca

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Wed, Sep 21, 2011 at 4:45 PM, Glenn Maynard wrote: > On Wed, Sep 21, 2011 at 6:51 PM, Eric U wrote: >> >> While it's certainly not hard to work around, as you say, it seems >> more complex and less likely to be obvious than the >> counter-for-activity examp

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

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 continue to match FileReader whatever else happens. Eric

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Wed, Sep 21, 2011 at 5:16 PM, Glenn Maynard wrote: > On Wed, Sep 21, 2011 at 7:51 PM, Eric U wrote: >> >> Again, that's not what the XHR2 spec says.  See my summary up-thread >> about the actual behavior, and Anne can correct my interpretation if >> I'm

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

Thanks Glenn and Simon--I'll see what I can do. On Fri, Sep 23, 2011 at 1:34 AM, Simon Pieters wrote: > On Fri, 23 Sep 2011 01:40:44 +0200, Glenn Maynard wrote: > > BlobBuilder.append(text) says: >> >> Appends the supplied text to the current contents of the BlobBuilder, >>> >> writing it as

Re: [FileAPI] BlobBuilder.append("native")

On Thu, Sep 22, 2011 at 4:47 PM, Glenn Maynard 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 was app

Re: Publishing specs before TPAC; Oct 14 is last day to start a CfC

On Mon, Sep 26, 2011 at 2:38 PM, Arthur Barstow 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 publication blackout period

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Thu, Sep 29, 2011 at 12:22 PM, Arun Ranganathan 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

Re: FileSystem API - The Flags interface

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 wrote: > Hello, > http://www.w3.org/TR/file-system-api/#the-flags-interface > If you look at the descript

Re: Is BlobBuilder needed?

On Mon, Oct 24, 2011 at 3:52 PM, 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); > bb.append(blob2); > bb.append("some

Re: Is BlobBuilder needed?

On Wed, Oct 26, 2011 at 4:14 PM, Jonas Sicking wrote: > On Tue, Oct 25, 2011 at 12:57 PM, Tab Atkins Jr. wrote: >> On Tue, Oct 25, 2011 at 12:53 PM, Ojan Vafai wrote: >>> The new API is smaller and simpler. Less to implement and less for web >>> developers to understand. If it can meet all our u

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking wrote: > On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard wrote: >> On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicking wrote: >>> >>> 1. Make "loadend" not fire in case a new load is started from >>> onabort/onload/onerror. Thus "loadend" and "loadstart" isn

Re: [File API] Calling requestFileSystem with bad filesystem type

On Fri, Oct 7, 2011 at 12:02 PM, Mark Pilgrim 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 errorCallback, so you shou

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Wed, Nov 2, 2011 at 3:56 PM, Jonas Sicking wrote: > On Wed, Nov 2, 2011 at 9:56 AM, Eric U wrote: >> On Mon, Oct 3, 2011 at 6:13 PM, Jonas Sicking wrote: >>> On Mon, Oct 3, 2011 at 5:57 PM, Glenn Maynard wrote: >>>> On Mon, Oct 3, 2011 at 8:10 PM, Jonas Sicki

Re: Is BlobBuilder needed?

On Tue, Nov 15, 2011 at 5:41 AM, Rich Tibbett 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); >> bb.

Re: Bug in file system Api specification

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

Re: File modification

On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard 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 date chan

Re: Colliding FileWriters

On Tue, Jan 10, 2012 at 1:08 PM, Jonas Sicking 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 the > file

Re: File modification

On Wed, Jan 11, 2012 at 12:22 PM, Charles Pritchard 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 input

Re: Colliding FileWriters

On Wed, Jan 11, 2012 at 12:25 PM, Jonas Sicking wrote: > On Tue, Jan 10, 2012 at 1:32 PM, Eric U wrote: >> On Tue, Jan 10, 2012 at 1:08 PM, Jonas Sicking wrote: >>> Hi All, >>> >>> We've been looking at implementing FileWriter and had a couple of questio

Re: [XHR] Invoking open() from event listeners

On Tue, Dec 20, 2011 at 9:24 AM, Anne van Kesteren 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 wrote: >> >> I think I may have missed something importan

Re: [file-writer] WebIDL / References

Thanks! I'll take care of those. On Sat, Feb 25, 2012 at 5:02 AM, Ms2ger wrote: > Hi all, > > There are a number of bugs in the WebIDL blocks in > . > > * The 'in' token has been removed; "void append (in Blob data);" should >  be "void ap

Re: CfC: publish WD of File API: Writer + File API: Directories and System; deadline March 3

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 wrote: > Hi, > > is there any reason why the File API: Writer and File API: Directories and > System specifications still use FileE

Re: Colliding FileWriters

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 wrote: > On Wed, Jan 11, 2012 at 1:41 PM, Eric U wrote: >> On Wed, Jan 11, 2012 at 12:25 PM, Jonas Sicking wrote: >>> On Tu

Re: [FileAPI, common] UTF-16 to UTF-8 conversion

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 wrote: > Thanks Glenn and Simon--I'll see what I can do. > > > On Fri, Sep 23

Re: [file-writer] WebIDL / References

On Sat, Feb 25, 2012 at 5:02 AM, Ms2ger wrote: > Hi all, > > There are a number of bugs in the WebIDL blocks in > . > > * The 'in' token has been removed; "void append (in Blob data);" should >  be "void append (Blob data);". Fixed. > * Ev

FileReader abort, again

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

Re: Colliding FileWriters

On Mon, Feb 27, 2012 at 4:40 PM, Jonas Sicking wrote: > On Mon, Feb 27, 2012 at 11:36 PM, Eric U wrote: >>>> One working subset would be: >>>> >>>> * Keep createFileWriter async. >>>> * Make it optionally exclusive [possibly by default].  If ex

Re: FileReader abort, again

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 wrote: > I like the Event Invariants writeup at the end.  It's only > informative

Re: FileReader abort, again

On Wed, Feb 29, 2012 at 1:43 PM, Arun Ranganathan 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 also terminat

Re: FileReader abort, again

On Wed, Feb 29, 2012 at 2:57 PM, Arun Ranganathan 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 has been

[fileapi] timing of readyState changes vs. events

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 c

Re: [fileapi] timing of readyState changes vs. events

On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan 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 from the blo

Re: [fileapi] timing of readyState changes vs. events

On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren wrote: > On Fri, 02 Mar 2012 01:01:55 +0100, Eric U wrote: >> >> On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan >> wrote: >>> >>> OK, so the change is to ensure that these events are fired directly, and

Re: FileReader abort, again

On Thu, Mar 1, 2012 at 11:20 AM, Arun Ranganathan 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 lo

Re: FileReader abort, again

On Mon, Mar 5, 2012 at 2:01 PM, Eric U wrote: > On Thu, Mar 1, 2012 at 11:20 AM, Arun Ranganathan > wrote: >> Eric, >> >>> >> > So we could: >>> >> > 1. Say not to fire a loadend if onloadend or onabort >>> >>> Do you mean

Re: [FileAPI] Deterministic release of Blob proposal

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 wrote: > At TPAC we discussed the ability to deterministically close blobs with a few > > ot

Re: Transferable and structured clones, was: Re: [FileAPI] Deterministic release of Blob proposal

On Wed, Mar 7, 2012 at 11:38 AM, Kenneth Russell wrote: > On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard wrote: >> On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman wrote: >>> >>> > You can always call close() yourself, but Blob.close() should use the >>> > "neuter" mechanism already there, not mak

Re: CfC: publish WD of File API: Writer + File API: Directories and System; deadline March 3

They're both updated to use DOM4's mechanisms now. On Mon, Feb 27, 2012 at 2:35 AM, Felix-Johannes Jendrusch wrote: > Hi, > > is there any reason why the File API: Writer and File API: Directories and > System specifications still use FileException/FileError-Objects? The File API > uses DOM4's

Re: [FileAPI] Deterministic release of Blob proposal

On Tue, Mar 6, 2012 at 5:12 PM, Feras Moussa 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] Deterministic release

Re: Colliding FileWriters

On Wed, Feb 29, 2012 at 8:44 AM, Eric U wrote: > On Mon, Feb 27, 2012 at 4:40 PM, Jonas Sicking wrote: >> On Mon, Feb 27, 2012 at 11:36 PM, Eric U wrote: >>>>> One working subset would be: >>>>> >>>>> * Keep createFileWriter async. >>&

Re: Delay in File * spec publications in /TR/ [Was: CfC: publish LCWD of File API; deadline March 3]

On Fri, Mar 30, 2012 at 5:39 AM, Arthur Barstow 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 published since

Re: BlobBuilder.append() should take ArrayBufferView in addition to ArrayBuffer

On Thu, Apr 12, 2012 at 12:54 PM, Anne van Kesteren wrote: > On Thu, 12 Apr 2012 21:48:12 +0200, Boris Zbarsky 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?  ;) > > > Eric, the plan is to r

Re: Colliding FileWriters

On Mon, Mar 19, 2012 at 3:55 PM, Jonas Sicking wrote: > On Wed, Feb 29, 2012 at 8:44 AM, Eric U wrote: >> On Mon, Feb 27, 2012 at 4:40 PM, Jonas Sicking wrote: >>> On Mon, Feb 27, 2012 at 11:36 PM, Eric U wrote: >>>>>> One working subset would be: >>

[File API] File behavior under modification

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

Re: Feedback on Quota Management API

On Wed, May 30, 2012 at 11:59 AM, Boris Zbarsky 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 on s

Re: [File API] File behavior under modification

Agreed. On Wed, Jul 11, 2012 at 1:02 PM, Arun Ranganathan wrote: > > On May 23, 2012, at 9:58 AM, Glenn Maynard wrote: > > On Wed, May 23, 2012 at 3:03 AM, Kinuko Yasuda wrote: >> >> Just to make sure, I assume 'the underlying storage' includes memory. > > > Right. For simple Blobs without a mu

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

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 and

Re: Sandboxed Filesystem use cases? (was Re: Moving File API: Directories and System API to Note track?)

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 handl

Re: [quota-api] Need for session storage type

On Tue, Oct 30, 2012 at 1:04 PM, Brady Eidson 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 wrote: > > Reviving this thread as well... to give a chance to get more feedbacks > before moving this forward. > > Let

FileSystem compromise spec

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 numb

Re: FileSystem compromise spec

On Fri, Nov 30, 2012 at 9:11 AM, SULLIVAN, BRYAN L 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 >>

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan 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 behavior and >

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Wed, May 1, 2013 at 4:53 PM, Jonas Sicking wrote: > On Wed, May 1, 2013 at 4:25 PM, Eric U wrote: >> On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan wrote: >>> Switching the default to "false" would enable IE, Chrome, andFirefox to >>> have interoperabi

Re: ZIP archive API?

On Mon, May 6, 2013 at 5:03 AM, Glenn Maynard wrote: > On Mon, May 6, 2013 at 6:27 AM, Robin Berjon 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. Without boiling the oc

Re: Blob URLs | autoRevoke, defaults, and resolutions

On Wed, May 1, 2013 at 5:16 PM, Glenn Maynard wrote: > On Wed, May 1, 2013 at 7:01 PM, Eric U 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, th

Re: FileSystem API

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 publi

Re: IndexedDB: Syntax for specifying persistent/temporary storage

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 explici

[fileapi-directories-and-system/filewriter]

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

[File API: FileSystem] Path restrictions and case-sensitivity

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 propos

Re: [File API: FileSystem] Path restrictions and case-sensitivity

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 rep

Re: [File API: FileSystem] Path restrictions and case-sensitivity

On Wed, May 11, 2011 at 4:47 PM, timeless wrote: > On Thu, May 12, 2011 at 2:08 AM, Eric U 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

Re: [File API: FileSystem] Path restrictions and case-sensitivity

On Wed, May 11, 2011 at 4:52 PM, Glenn Maynard wrote: > On Wed, May 11, 2011 at 7:08 PM, Eric U wrote: >> >> > *everywhere*, both on Turkish and on English systems. Things could >> > only be case sensitive when serialized to a real file system outside >> >

Re: [File API: FileSystem] Path restrictions and case-sensitivity

On Wed, May 11, 2011 at 7:14 PM, Jonas Sicking wrote: > On Wednesday, May 11, 2011, Eric U 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 "IMAG

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Tue, May 17, 2011 at 2:41 PM, Jonas Sicking wrote: > On Tue, May 17, 2011 at 2:35 PM, Kyle Huey 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 under way, while the reading o

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

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 wrot

Re: [FileAPI] FileReader.abort() and File[Saver|Writer].abort have different behaviors

On Tue, May 17, 2011 at 2:48 PM, Jonas Sicking wrote: > On Tue, May 17, 2011 at 2:42 PM, Eric U 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

Re: [File API: FileSystem] Path restrictions and case-sensitivity

On Thu, May 12, 2011 at 1:34 AM, timeless wrote: > On Thu, May 12, 2011 at 3:02 AM, Eric U 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

[File API: FileSystem] Removed mimeType from toURL

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