[Bug 10623] Simplify Web IDL exceptions

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623

Cameron McCormack  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Cameron McCormack  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
.  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.

[Bug 10622] ECMAScript binding for exceptions

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10622

Cameron McCormack  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Cameron McCormack  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.

Re: CfC: new WD of Clipboard API and Events; deadline April 5

[Daniel Cheng]

On Sun, Apr 10, 2011 at 11:30, Charles McCathieNevile wrote:

> comments on a couple of timeless' comments.
>
>
> On Sun, 10 Apr 2011 18:20:35 +0200, timeless  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

RE: publish new Working Draft of Indexed Database API; deadline April 16

[Adrian Bateman]

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: [FileAPI] FileWriter and read-only files

[Charles Pritchard]

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.

 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 , but I'd like some method to make it 
easier for users

to open and save multiple files to their computer.

Re: [FileAPI] FileWriter and read-only files

[Glenn Maynard]

On Mon, Apr 11, 2011 at 5:32 PM, Ian Hickson  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 
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

[Ian Hickson]

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

[Glenn Maynard]

On Mon, Apr 11, 2011 at 4:22 PM, Eric Uhrhane  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  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,  to ask
> > for write permission (setting readOnly if only read permission was
> granted,
> > eg. with an "open read-only" checkbox), and 
> 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  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  and FileReader,
but we can't do the same for writing with  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

[Eric Uhrhane]

On Mon, Apr 11, 2011 at 12:16 PM, Glenn Maynard  wrote:
> File objects should have a "readOnly" property, indicating whether write
> permission is granted by the user.  Files returned from  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  to allow
> opening files for write.  For example,  to ask
> for write permission (setting readOnly if only read permission was granted,
> eg. with an "open read-only" checkbox), and  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

[FileAPI] FileWriter and read-only files

[Glenn Maynard]

File objects should have a "readOnly" property, indicating whether write
permission is granted by the user.  Files returned from  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  to allow
opening files for write.  For example,  to ask
for write permission (setting readOnly if only read permission was granted,
eg. with an "open read-only" checkbox), and  to
also ask the browser to show a "Save As" dialog instead of an "Open" dialog.

-- 
Glenn Maynard

RE: [FileAPI] Result of calling MultipleReads on FileReader

[Adrian Bateman]

On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote:
> On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathan  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.

Re: [FileAPI] Result of calling MultipleReads on FileReader

[Glenn Maynard]

On Mon, Apr 11, 2011 at 1:28 PM, Arun Ranganathan  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

[Arun Ranganathan]

On 4/11/11 1:04 PM, Glenn Maynard wrote:
On Mon, Apr 11, 2011 at 12:33 PM, Arun Ranganathan > 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

[Eric Uhrhane]

On Mon, Apr 11, 2011 at 9:05 AM, 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.

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

[Glenn Maynard]

On Mon, Apr 11, 2011 at 12:33 PM, Arun Ranganathan  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: Offline Web Applications status

[Michael Nordman]

2011/4/7 Michael Nordman 

>
>
> 2011/4/7 louis-rémi BABE 
>
>> 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: 
>> 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  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. 
> > 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), 
>
> The summary is that the  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

[Arun Ranganathan]

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: [FileAPI] Seeking status and plan

[Arthur Barstow]

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

[Adrian Bateman]

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: Support for matchesSelector()

[Lachlan Hunt]

On 2011-04-10 13:32, Lachlan Hunt wrote:

On 2011-04-08 16:41, Boris Zbarsky wrote:

On 4/8/11 6:44 AM, Lachlan Hunt wrote:

We are thinking that implementing with a prefix as
Element.oMatchesSelector() is unnecessary


After taking Boris' feedback into account, we decided that we'll keep 
the prefix for now.  It will be implemented as oMatchesSelector(), when 
it eventually makes it into a release build.


Also, just FYI, I updated the prose of the spec to match the recent IDL 
changes for refNodes, discussed elsewhere in this thread.  Feedback on 
that would be appreciated.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [FileAPI] Result of calling MultipleReads on FileReader

[Arun Ranganathan]

On 3/31/11 6:12 PM, Eric Uhrhane wrote:

On Thu, Mar 31, 2011 at 2:55 PM, Adrian Bateman  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 Bateman

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] Seeking status and plan

[Arun Ranganathan]

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*

[FileAPI] Seeking status and plan

[Arthur Barstow]

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