[FileAPI] Seeking status and plan
Hi Arun, Jonas - what is the status/plan for the File API spec? What remains to be done before the spec is LC ready? (Tracker shows 0 bugs and WebApps does not have a Bugzilla component for this spec). -Thanks, AB
Re: [FileAPI] Seeking status and plan
On 4/11/11 9:38 AM, Arthur Barstow wrote: Hi Arun, Jonas - what is the status/plan for the File API spec? What remains to be done before the spec is LC ready? Art: A few things need to be done: 1. There continue to be a few spec. nits about multiple read calls; these have to be addressed. 2. We'll have to make the pieces of the spec. that address asynchronous events more in keeping with HTML5 3. There'll have to be some discussion about the blob: scheme. (Tracker shows 0 bugs and WebApps does not have a Bugzilla component for this spec). We can use Tracker and create the component if it is helpful; we used the public listserv and didn't really use the Bugzilla component or Tracker (except after F2Fs). Regarding plan: I'd like to tackle 1-3 (allowing time for discussion), and put this on the LC track by May 1. Does that seem acceptable? -- A*
Re: [FileAPI] Result of calling MultipleReads on FileReader
On 3/31/11 6:12 PM, Eric Uhrhane wrote: On Thu, Mar 31, 2011 at 2:55 PM, Adrian Batemanadria...@microsoft.com wrote: On Thursday, March 31, 2011 10:19 AM, Arun Ranganathan wrote: On 3/30/11 2:01 PM, Eric Uhrhane wrote: On Mon, Mar 28, 2011 at 5:37 PM, Adrian Batemanadria...@microsoft.com wrote: Is there a reason for the current spec text? I don't know the original rationale, but in the absence of any strong technical constraint, I'd much prefer that subsequent read calls just throw an exception immediately. They seem likely to be indicative of bad code anyway, and it's so much easier to debug when you find out right away. The original rationale was to do what XHR does w.r.t. open()! Essentially, the goal was: 1. To abort previous reads in favor of the last one, like how XHR does. 2. The last read goes through. So: Adrian/Eric -- do you object to keeping this like XHR in terms of aborting previous reads? What I should *definitely* do is make spec. text more robust to reflect this; in general I want to make asynchronous parts of this spec. more like HTML5 here. I think it's cleaner and simpler just to throw. FileReader and XHR are already different enough that a bit more, as long as it's a usability improvement, isn't a big deal. The efficiency improvement is just a bonus. Eric: are you sure you mean throw or do you mean, fire error event or abort? Note that only FileReaderSync (running on threads) actually throws in terms of an exception. As long as the spec is clear I don't mind whether a subsequent read throws or includes an implicit abort() call. That's not the way I read the current spec text. We need to know things like whether we should queue any events for the abort or just silently move on to the new read, etc. It would be good if we can be explicit about when you're allowed to call readAs (this way it sounds like always) and if anything is different between the LOADING and DONE states. Agreed on the need for this to be very explicit. But I think we should skip all the extra queued events by just making it illegal. Eric: can you be a bit more explicit about what you mean by illegal? I'm fully on board with being more explicit BTW, and want to address Adrian's nits (and yours) in an update to the specification. -- A*
RE: [FileAPI] Result of calling MultipleReads on FileReader
On Monday, April 11, 2011 8:28 AM, Arun Ranganathan wrote: On 3/31/11 6:12 PM, Eric Uhrhane wrote: I think it's cleaner and simpler just to throw. FileReader and XHR are already different enough that a bit more, as long as it's a usability improvement, isn't a big deal. The efficiency improvement is just a bonus. Eric: are you sure you mean throw or do you mean, fire error event or abort? Note that only FileReaderSync (running on threads) actually throws in terms of an exception. I think throwing an exception would be appropriate here. The FileReader will know synchronously that it is already doing a read and that calling read again is an invalid operation. Firing the error event should be reserved for errors that come from the operation of the reader and not because the developer called it incorrectly. Cheers, Adrian.
Re: [FileAPI] Seeking status and plan
On Apr/11/2011 11:20 AM, ext Arun Ranganathan wrote: On 4/11/11 9:38 AM, Arthur Barstow wrote: Hi Arun, Jonas - what is the status/plan for the File API spec? What remains to be done before the spec is LC ready? Art: A few things need to be done: 1. There continue to be a few spec. nits about multiple read calls; these have to be addressed. 2. We'll have to make the pieces of the spec. that address asynchronous events more in keeping with HTML5 3. There'll have to be some discussion about the blob: scheme. (Tracker shows 0 bugs and WebApps does not have a Bugzilla component for this spec). We can use Tracker and create the component if it is helpful; we used the public listserv and didn't really use the Bugzilla component or Tracker (except after F2Fs). Regarding plan: I'd like to tackle 1-3 (allowing time for discussion), and put this on the LC track by May 1. Does that seem acceptable? Thanks Arun; yes that sounds good. -AB
Re: [FileAPI] Result of calling MultipleReads on FileReader
On 4/11/11 12:05 PM, Adrian Bateman wrote: On Monday, April 11, 2011 8:28 AM, Arun Ranganathan wrote: On 3/31/11 6:12 PM, Eric Uhrhane wrote: I think it's cleaner and simpler just to throw. FileReader and XHR are already different enough that a bit more, as long as it's a usability improvement, isn't a big deal. The efficiency improvement is just a bonus. Eric: are you sure you mean throw or do you mean, fire error event or abort? Note that only FileReaderSync (running on threads) actually throws in terms of an exception. I think throwing an exception would be appropriate here. The FileReader will know synchronously that it is already doing a read and that calling read again is an invalid operation. Firing the error event should be reserved for errors that come from the operation of the reader and not because the developer called it incorrectly. In general, I'm averse to throwing, since I think it puts an additional burden on the developer (to catch, for example). On the main thread, with your proposal, all reads will stop since an exception has been raised. Of course, when all reads are synchronous, throwing makes sense, since we're not generating events that the developer listens for. Thus, in the case of FileReaderSync, I'll introduce spec. text (and more WebIDL formalism) that makes it clear that multiple reads will raise a FileException. On the main thread, what we have now (which, as you correctly point out, needs to be better defined) is that the previous read aborts, but the latest call goes through. I like this since at least some result is obtained, rather than an exception. The burden on the vigilant developer is to watch for errors, but the developer can at least obtain the result of the latest read call without an exception. I'm absolutely resolved to providing better specification text, but I'm pushing back on the matter of throwing on the main thread, since I believe it may actually be easier. In both scenarios, we don't allow for multiple simultaneous reads (e.g. you can't simultaneously read as text and as binary). Do you disagree strongly? -- A*
Re: Offline Web Applications status
2011/4/7 Michael Nordman micha...@google.com 2011/4/7 louis-rémi BABE lrb...@gmail.com Thank you all for your valuable answers. There seems to be a pretty solid agreement on ability to exclude the master page form the cache. Michael, you are suggesting using a different way of referring to the manifest: http useManifest='x' Why not just let it be listed in the NETWORK section of the manifest? It would make the means of including or excluding resources from the cache more consistent. I think the html tag syntax is a better API for the reasons mentioned in the whatwg list, i'll reiterate them here... A few ideas on syntax... a. html useManifest='x' b. If the main resource has a no-store header, don't add it to the cache, but do associate the document with the cache. c. A new manifest section to define a prefix matched namespace for these pages. Option (c) isn't precisely targeted at individual resources, authors would have to arrange their URL namespace more carefully to achieve the desired results. Option (a) and (b) can be applied specifically to individual pages offering greater control over. And option (a) is the more explicit the two. Authors need only edit the page to get the desired result instead of having to arrange for the appropiate http headers. Readers of the code (and view sourcers of the pages) can more easily determine how this page should utilize the appcache just by looking at the source of the page. My pick would be option (a), html useManifest='x' The summary is that the html useManifest='x' is cleaner and clearer imo. The NETWORK section doesn't actually exclude resources from being added to the cache. For example you can explicitly list a url in the CACHE section, and again in the NETWORK section... guess what... the resource is added to the cache and will be utilized. Also, I'm looking for a syntax that adds this new capability in a non-breaking way. I want to avoid changing the semantics of the any existing API since it's already shipped. Allow cross-origin HTTPS resources to be included in manifest files. This much is actually done already in chromium impl as described on the whatwg list. Is it already available in a stable version of Chrome? Chrome 11 should hit the stable channel in ~18 days. It's in the beta channel now. I would also like to see this one fully implemented in Firefox asap. I'll get in touch with our developers. Fantastic! I'll open a bug in webkit to do the same since. Micheal, have you got use-cases for the 4th and 5th feature request of this thread [1]? This feature is more architecture driven than use-case driven. Without such a feature, while in many cases there may be a way to produce a solution that functions 'offline', the trouble is that it's a completely different solution than in the 'online' case. I'll follow up with you about these features in particular. And could you please keep me updated with your implementation efforts in Chromium? I would be very happy to and likewise would be appreciated. Regards, Louis-Rémi [1] http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/1121.html
Re: [FileAPI] Result of calling MultipleReads on FileReader
On Mon, Apr 11, 2011 at 12:33 PM, Arun Ranganathan a...@mozilla.com wrote: In general, I'm averse to throwing, since I think it puts an additional burden on the developer (to catch, for example). Only if the developer is trying to catch all exceptions, which you usually don't. Most developers don't try to catch exceptions that indicate API usage errors, like element.appendChild(element); they just let the exception propagate and fix the bug. I think it makes sense to throw an exception here. Callbacks should indicate the result of a successful call to an async method, but if the method *itself* (not the async operation it queues) failed, throw. Note that FileReader methods already throw an exception in Firefox, eg. new FileReader().readAsBinaryString(null). I'm not sure if that particular case is to spec, but it makes a lot more sense than using onerror. On the main thread, with your proposal, all reads will stop since an exception has been raised. That's odd--why would that happen? Normally one expects an API call that throws an exception to have no effect. It'd be particularly strange if some exceptions cancel the previous read and others didn't. -- Glenn Maynard
Re: [FileAPI] Result of calling MultipleReads on FileReader
On Mon, Apr 11, 2011 at 9:05 AM, Adrian Bateman adria...@microsoft.com wrote: On Monday, April 11, 2011 8:28 AM, Arun Ranganathan wrote: On 3/31/11 6:12 PM, Eric Uhrhane wrote: I think it's cleaner and simpler just to throw. FileReader and XHR are already different enough that a bit more, as long as it's a usability improvement, isn't a big deal. The efficiency improvement is just a bonus. Eric: are you sure you mean throw or do you mean, fire error event or abort? Note that only FileReaderSync (running on threads) actually throws in terms of an exception. I think throwing an exception would be appropriate here. The FileReader will know synchronously that it is already doing a read and that calling read again is an invalid operation. Firing the error event should be reserved for errors that come from the operation of the reader and not because the developer called it incorrectly. My thoughts exactly. That's the way I've structured things in FileWriter as well. I think it's much better to find out about bad code as soon as possible. On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathan a...@mozilla.com wrote: In general, I'm averse to throwing, since I think it puts an additional burden on the developer (to catch, for example). I don't think so. I think that calling two read methods is the kind of thing that will come up in initial testing, the exception won't be caught at all, and thus will be noticed and the bug removed. On the main thread, with your proposal, all reads will stop since an exception has been raised. Of course, when all reads are synchronous, throwing makes sense, since we're not generating events that the developer listens for. Thus, in the case of FileReaderSync, I'll introduce spec. text (and more WebIDL formalism) that makes it clear that multiple reads will raise a FileException. On the main thread, what we have now (which, as you correctly point out, needs to be better defined) is that the previous read aborts, but the latest call goes through. I like this since at least some result is obtained, rather than an exception. I'd *much* rather have an exception than silently get some random result depending on which method I accidentally called last. The burden on the vigilant developer is to watch for errors, but the developer can at least obtain the result of the latest read call without an exception.
Re: [FileAPI] Result of calling MultipleReads on FileReader
On 4/11/11 1:04 PM, Glenn Maynard wrote: On Mon, Apr 11, 2011 at 12:33 PM, Arun Ranganathan a...@mozilla.com mailto:a...@mozilla.com wrote: In general, I'm averse to throwing, since I think it puts an additional burden on the developer (to catch, for example). Only if the developer is trying to catch all exceptions, which you usually don't. Most developers don't try to catch exceptions that indicate API usage errors, like element.appendChild(element); they just let the exception propagate and fix the bug. I think it makes sense to throw an exception here. Callbacks should indicate the result of a successful call to an async method, but if the method *itself* (not the async operation it queues) failed, throw. Note that FileReader methods already throw an exception in Firefox, eg. new FileReader().readAsBinaryString(null). I'm not sure if that particular case is to spec, but it makes a lot more sense than using onerror. The spec. should absolutely say when an exception is raised for scenarios that you point out above, and I should add this in (currently we don't say anything about that scenario). I guess the question here is what to do in the multiple reads scenario. On the main thread, with your proposal, all reads will stop since an exception has been raised. That's odd--why would that happen? Normally one expects an API call that throws an exception to have no effect. It'd be particularly strange if some exceptions cancel the previous read and others didn't. I'm sorry, I'm misunderstanding. Seems like the behavior with exceptions is that if there are multiple reads, previous ones raise exceptions, but that the latest is processed (assuming no errors, etc.). Is that correct? -- A*
Re: [FileAPI] Result of calling MultipleReads on FileReader
On Mon, Apr 11, 2011 at 1:28 PM, Arun Ranganathan a...@mozilla.com wrote: On the main thread, with your proposal, all reads will stop since an exception has been raised. That's odd--why would that happen? Normally one expects an API call that throws an exception to have no effect. It'd be particularly strange if some exceptions cancel the previous read and others didn't. I'm sorry, I'm misunderstanding. Seems like the behavior with exceptions is that if there are multiple reads, previous ones raise exceptions, but that the latest is processed (assuming no errors, etc.). Is that correct? I interpreted what you said to mean that if you did this: fr.readAsBinaryString(blob1); fr.readAsDataURL(blob2); and the readAsDataURL call raised an exception (not an error event), the operation started by readAsBinaryString would stop. I think that here, readAsDataURL should throw an exception, and the readAsBinaryString's operation should continue as if readAsDataURL was never called. -- Glenn Maynard
RE: [FileAPI] Result of calling MultipleReads on FileReader
On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote: On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathan a...@mozilla.com wrote: In general, I'm averse to throwing, since I think it puts an additional burden on the developer (to catch, for example). I don't think so. I think that calling two read methods is the kind of thing that will come up in initial testing, the exception won't be caught at all, and thus will be noticed and the bug removed. On the main thread, with your proposal, all reads will stop since an exception has been raised. Of course, when all reads are synchronous, throwing makes sense, since we're not generating events that the developer listens for. Thus, in the case of FileReaderSync, I'll introduce spec. text (and more WebIDL formalism) that makes it clear that multiple reads will raise a FileException. I'd *much* rather have an exception than silently get some random result depending on which method I accidentally called last. The burden on the vigilant developer is to watch for errors, but the developer can at least obtain the result of the latest read call without an exception. I agree with Eric - I prefer to fail fast when the developer has misused an API. It makes it much easier to see that there is a mistake and debug why. So the key question to me is Is this misuse? I can't think of a good use case where a developer would want to call read again during the LOADING state and expect that the correct behaviour would be to implicitly call abort(). That doesn't seem like a common scenario. In the EMPTY or DONE states makes perfect sense - that makes FileReader reusable - but during LOADING I think is a developer mistake. Cheers, Adrian.
[FileAPI] FileWriter and read-only files
File objects should have a readOnly property, indicating whether write permission is granted by the user. Files returned from input elements should, by default, set it. Constructing a FileWriter using a File with its readOnly property set should throw an exception. Later, it would be good to also have an attribute on input to allow opening files for write. For example, input type=file file=write to ask for write permission (setting readOnly if only read permission was granted, eg. with an open read-only checkbox), and input type=file file=create to also ask the browser to show a Save As dialog instead of an Open dialog. -- Glenn Maynard
Re: [FileAPI] FileWriter and read-only files
On Mon, Apr 11, 2011 at 12:16 PM, Glenn Maynard gl...@zewt.org wrote: File objects should have a readOnly property, indicating whether write permission is granted by the user. Files returned from input elements should, by default, set it. Constructing a FileWriter using a File with its readOnly property set should throw an exception. Are you thinking of FileEntry? File objects are always immutable, and there's currently no way to get from a File to a FileWriter. Having an immutable flag on a FileEntry would make sense, but as there's currently no API to get a FileWriter outside of the FileSystem [which has no immutable files], there's no rush to put it in--it can wait for an API expansion that would let you get such a thing. Later, it would be good to also have an attribute on input to allow opening files for write. For example, input type=file file=write to ask for write permission (setting readOnly if only read permission was granted, eg. with an open read-only checkbox), and input type=file file=create to also ask the browser to show a Save As dialog instead of an Open dialog. We discussed this a while back, and people generally preferred something like FileSaver instead of markup. Eric
Re: [FileAPI] FileWriter and read-only files
On Mon, Apr 11, 2011 at 4:22 PM, Eric Uhrhane er...@google.com wrote: Are you thinking of FileEntry? File objects are always immutable, and there's currently no way to get from a File to a FileWriter. I'm thinking of File, but I didn't notice that there's no FileWriter(File) constructor. I suppose the answer, in this case, would be something like adding a createWriter method to the objects in the HTMLInputElement.files array (a new subclass of File), to create a writer for the underlying file. In that case, there's no need for an additional readOnly property: if you don't have permission to write to the file then the list item would just be a File, with no createWriter method. As an aside: I don't understand File being immutable. The underlying file on disk isn't; it may change between the user selecting it with input and the script reading it. Browsers don't read the entire contents of files before exposing them in input.files, of course. What's supposed to happen here? It seems like File is trying to act like an immutable Blob, but doing so by referencing a resource that isn't. opening files for write. For example, input type=file file=write to ask for write permission (setting readOnly if only read permission was granted, eg. with an open read-only checkbox), and input type=file file=create to also ask the browser to show a Save As dialog instead of an Open dialog. Later, it would be good to also have an attribute on input to allow We discussed this a while back, and people generally preferred something like FileSaver instead of markup. FileSaver only works if you're writing an entire file; it doesn't allow updating or appending to an existing file. Handling these cases is the very reason FileWriter exists in the first place, isn't it? It's also not ideal for writing very large files. Although nothing requires browsers keep Blobs in memory (they can, and probably should, scratch to disk for very large blobs), if you're writing several gigabytes of data, that implies doubling disk access and storage, as the data is copied from temporary storage to the target file. It seems asymmetric that we can open and read with input and FileReader, but we can't do the same for writing with input and FileWriter. I understand if this isn't something to do just yet, but I hope it won't be written off entirely. -- Glenn Maynard
Re: [FileAPI] FileWriter and read-only files
On Mon, 11 Apr 2011, Glenn Maynard wrote: createWriter method to the objects in the HTMLInputElement.files array (a new subclass of File), to create a writer for the underlying file. That would violate the user expectation that files provided using a file upload control on a form can't be damaged by the site. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [FileAPI] FileWriter and read-only files
On Mon, Apr 11, 2011 at 5:32 PM, Ian Hickson i...@hixie.ch wrote: createWriter method to the objects in the HTMLInputElement.files array (a new subclass of File), to create a writer for the underlying file. That would violate the user expectation that files provided using a file upload control on a form can't be damaged by the site. To enable this, you would say something like input type=file file=writable as I suggested earlier, which would allow the UA to show appropriate information to the user. -- Glenn Maynard
Re: [FileAPI] FileWriter and read-only files
On 4/11/2011 2:32 PM, Ian Hickson wrote: On Mon, 11 Apr 2011, Glenn Maynard wrote: createWriter method to the objects in the HTMLInputElement.files array (a new subclass of File), to create a writer for the underlying file. That would violate the user expectation that files provided using a file upload control on a form can't be damaged by the site. At some point, I imagine we'll be allowing authors+users to mount arbitrary directories for reading and writing. input webkitDirectory doesn't quite cut it, requestFileSystem is being re-purposed to to no longer have a direct mapping to the OS FS. It may not be input type=file, but I'd like some method to make it easier for users to open and save multiple files to their computer.
RE: publish new Working Draft of Indexed Database API; deadline April 16
On Saturday, April 09, 2011 4:23 AM, Arthur Barstow wrote: The Editors of the Indexed Database API would like to publish a new Working Draft of their spec and this is a Call for Consensus to do so: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html If one agrees with this proposal, it: a) indicates support for publishing a new WD; and b) does not necessarily indicate support for the contents of the WD. If you have any comments or concerns about this proposal, please send them to public-webapps by April 16 at the latest. As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be agreement with the proposal. Microsoft supports this.
Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Sun, Apr 10, 2011 at 11:30, Charles McCathieNevile cha...@opera.comwrote:
comments on a couple of timeless' comments.
On Sun, 10 Apr 2011 18:20:35 +0200, timeless timel...@gmail.com wrote:
Calling clearData() empties the system clipboard, or removes the specified
type of data from the clipboard. See HTML5 for details [HTML5].
This has issues. If the user has inserted something the user cares
about into the system clipboard, then allowing a web page to stomp on
it is annoying. Something needs to protect the user from such web
apps.
Yes - should that comment be on HTML5 though, or alternatively is there a
reason not to copy it?
I'm not sure the spec needs to go out of its way to guard against this.
Typically, when writing to a clipboard, you'd clear all the data on the
clipboard before writing the new data; otherwise, you might end up with text
from one window, HTML from another, and a URL from a third. A page that
wanted to stomp on user data could simply do something like
event.clipboardData.setData('text/plain', '').
Daniel
[Bug 10622] ECMAScript binding for exceptions
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10622 Cameron McCormack c...@mcc.id.au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Cameron McCormack c...@mcc.id.au 2011-04-12 02:59:41 UTC --- Exceptions now do inherit from Error, and the value of the name property is defined to be the same as the identifier of the exception. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 10623] Simplify Web IDL exceptions
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623
Cameron McCormack c...@mcc.id.au changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||WONTFIX
--- Comment #1 from Cameron McCormack c...@mcc.id.au 2011-04-12 03:02:29 UTC
---
Exceptions have been changed so that you can now inherit one from another, with
a view to not requiring codes for newly defined exceptions, per
http://www.w3.org/mid/20101217180920.ga31...@wok.mcc.id.au. In the simple
case for new exceptions where you don't need an inheritance hierarchy for them,
you would just write:
interface MyNewException { };
which will be sufficient for testing against with either `e instanceof
MyNewException` or `e.name == MyNewException`.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
