Re: [File API] abort()

[Arun Ranganathan]

Anne,

> On Fri, 03 Dec 2010 16:43:00 +0100, Arun Ranganathan
>  wrote:
> > - Original Message -
> >> Per http://dev.w3.org/2006/webapi/FileAPI/#abort invoking abort()
> >> always
> >> results in events getting dispatched. This is not what happens in
> >> e.g.
> >> Gecko at the moment. When the state is EMPTY the method simply
> >> returns.
> >
> > To be clear, what is the behavior you are prescribing? Chrome folks,
> > what is the desired behavior for your implementation?
> 
> That when the state of the object is EMPTY the abort() method returns
> directly rather than dispatching a bunch of events as per the current
> specification. There are actually tests in the Mozilla repository that
> contradict the current specification.


I spoke to Jonas, and we're definitely correcting this.  I think that:

1. When the state is NOT EMPTY, we shouldn't fire error but other steps are 
probably ok.
2. When the state is EMPTY, we should behave as you prescribe.

> 
> 
> >> The dispatching of events should probably also be defined in terms
> >> of
> >> the event queue so it becomes more clear which are to be dispatched
> >> synchronously, etc. Currently all those interactions are quite
> >> vague
> >> in the File API specification.
> >
> > OK, I agree that this could be better, and should be improved in a
> > subsequent version (especially making clear synchronous dispatch).
> > If
> > you could be more specific about your nits, that would help as well.
> 
> What do you mean with subsequent version?

Sorry to be unclear: I only meant the editor's draft, which currently matches 
the TR, but will change based on feedback we've received after the TPAC.

> 
> What I am basically saying is that for the events that are clearly not
> dispatched synchronously (e.g. reading from a Blob is an asynchronous
> operation) the specification ought to define this in terms of the
> HTML5
> event loop model. Much like e.g. XMLHttpRequest and Web Workers do.


I agree with this.

-- A*

Re: Seeking status of Server-sent Events, Web Storage and Web Workers

[Ian Hickson]

On Mon, 6 Dec 2010, Charles Pritchard wrote:
> On 12/6/2010 1:08 PM, Ian Hickson wrote:
> > On Mon, 6 Dec 2010, Arthur Barstow wrote:
> > > Since Hixie is active on HTML, perhaps someone else is willing to pick
> > > one of these LCs and to review the issues, bugs, diffs, etc. and propose
> > > the next step . Any volunteers?
> > I am responding to feedback on these specs, just not on the schedule I
> > described earlier this year. (For instance, I just committed a change to
> > Web Storage.) My lack of urgency on getting things to CR stems primarily
> > from my disillusionment with the entire process; Web specs should just be
> > continuously maintained, having snapshots on the TR/ page seems to have
> > only one positive side-effect, and that's the effect on the patent policy.
> > Other than that it just provides a distraction that implementors and
> > authors can end up referencing instead of the more up-to-date and
> > continually maintained draft.
> > 
> > The drafts are actively maintained, and feedback is tracked and addressed.
> > It's just not done with the goal of reaching the TR/ page, but rather with
> > the goal of fostering interoperable implementations.
> 
> Static section numbers, and patent policy are quite important to the 
> lawyer crowd.
> 
> I agree, it's just one positive side-effect, but it's a big one.

If anyone wants to just take the draft and regularly publish a REC 
snapshot of it for patent policy purposes, that's fine by me, provided 
the snapshot is suitably marked as being a snapshot for that purpose and 
doesn't profess to being the latest version.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Seeking status of Server-sent Events, Web Storage and Web Workers

[Ian Hickson]

On Mon, 6 Dec 2010, Arthur Barstow wrote:
> 
> Since Hixie is active on HTML, perhaps someone else is willing to pick 
> one of these LCs and to review the issues, bugs, diffs, etc. and propose 
> the next step . Any volunteers?

I am responding to feedback on these specs, just not on the schedule I 
described earlier this year. (For instance, I just committed a change to 
Web Storage.) My lack of urgency on getting things to CR stems primarily 
from my disillusionment with the entire process; Web specs should just be 
continuously maintained, having snapshots on the TR/ page seems to have 
only one positive side-effect, and that's the effect on the patent policy. 
Other than that it just provides a distraction that implementors and 
authors can end up referencing instead of the more up-to-date and 
continually maintained draft.

The drafts are actively maintained, and feedback is tracked and addressed. 
It's just not done with the goal of reaching the TR/ page, but rather with 
the goal of fostering interoperable implementations.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: using BlobBuilder append method with generated binary data

[Paul Kinlan]

That's what I thought when I first looked at it, however you can pre-set the
array length and then iterate over every byte and set it. It is not ideal,
but works.  I have it running on http://appmator.appspot.com/ but it
basically boils down to the following:

var ui8a = new Uint8Array(output.length);

for(var i = 0; i< output.length; i++) {
  ui8a[i] = output.charCodeAt(i);
}

bb.append(ui8a.buffer);

var blob = bb.getBlob("application/octet-stream");

var saveas = document.createElement("iframe");
saveas.style.display = "none";
saveas.src = window.createObjectURL(blob);

P

On Mon, Dec 6, 2010 at 8:34 PM, Toni Ruottu  wrote:

> I do not think UInt8Array has any data. It is just a view for
> accessing the buffer.
>
>  --Toni
>
> On Sat, Dec 4, 2010 at 1:12 AM, Paul Kinlan  wrote:
> > I might have missed something but for appending client-side generated
> > data to a blob can't you just append a UInt8Array as that is based off
> > ArrayBuffer?
> >
> > I use it to generate zip files client side and attach them to an
> > iframe so they are downloaded.
> >
> > P
> > On Thursday, December 2, 2010, Toni Ruottu  wrote:
> >> My code had a bug in it. The APIs seem to be working ok for my purposes.
> >> Using the APIs, I was able to write Firefox's sendAsBinary method for
> chrome.
> >> It is available from http://javascript0.org/wiki/Portable_sendAsBinary
> >>
> >>   --Toni
> >>
> >> On Tue, Nov 16, 2010 at 5:25 PM, Toni Ruottu 
> wrote:
> >>> Sorry for slow answer. Took me a while to get on top of this. I think
> >>> they just might answer my problem. However, I can not really tell
> >>> before I see a working implementation. I wrote a test. See
> >>> http://www.cs.helsinki.fi/u/twruottu/testi/bpost3.html It does not
> >>> currently work with the latest development version of Chrome. I
> >>> wonder, if I am doing something wrong.
> >>>
> >>>  --Toni
> >>>
> >>> On Wed, Oct 20, 2010 at 6:17 PM, Eric Uhrhane 
> wrote:
>  Toni:
> 
> BlobBuilder now has an append() method that takes an ArrayBuffer,
>  and FileReader has readAsArrayBuffer.  Do these together satisfy your
>  needs?
> 
> Eric
> 
>  On Wed, Oct 20, 2010 at 3:39 AM, Toni Ruottu 
> wrote:
> > I have discussed the topic before on some Chromium bug threads. I
> > searched the archives of this mailing list for blobs and generated
> > content, but was not too successful. There may be multiple different
> > reasons why one would need to build blobs from generated data. The
> one
> > that concerns me, is being able to do binary POSTs with
> XmlHTTPRequest
> > in a standard manner. To send binary data over XHR one is required to
> > send out a blob, but first the blob needs to be constructed with
> > BlobBuilder. Let me fill you in on how I see the current situation.
> > Maybe someone can spot an error in my line of thought.
> >
> > A new (empty) BlobBuilder is created by stating...
> > var bb = new BlobBuilder();
> >
> > After creating a BlobBuilder, the user appends some data into the
> blob
> > being generated by using the append function. The append function is
> > overloaded and can be used to append multiple different types of data
> > into the blob. Currently only existing blobs, and utf-8 text are
> > supported.
> >
> > One can add an existing blob into the new one by doing...
> > bb.append(existingBlob);
> >
> > One can add a text string in utf-8 format by doing...
> > bb.append(aTextString);
> >
> > Once the data is in there, it is possible to construct the new blob
> with...
> > var blob = bb.getBlob()
> >
> > A blob has a slice method which makes it possible to turn a large
> blob
> > into smaller ones. It is thus possible to cut out single bytes from a
> > blob and use them construct new blobs by appending copies of these
> > sample bytes together with the BlobBuilder.
> >
> > As sample bytes can only be generated by writing text into the blob
> as
> > utf-8, it is not possible to generate all 8-bit patterns. More
> > specifically, the bit patterns that are illegal in any given utf-8
> > string, are not possible to generate using the current API. This
> leads
> > developers into using various hacks to overcome the issue.
> >
> > For example one could ask the user to provide a file with sample
> > bytes. Methods for reading a file into a blob are available, so there
> > is no need to generate the sample bytes. There is however no way to
> > make sure that the user provided a file with correct bit-patterns as
> > the blob interface is to a large degree a read-only interface. A
> > demonstration of using a file to overcome the issue is available at
> > http://www.cs.helsinki.fi/u/twruottu/testi/bpost.html
> >
> > To solve the problem a third append function which accepts a list of
> > integers, and adds the corres

Re: using BlobBuilder append method with generated binary data

[Toni Ruottu]

I do not think UInt8Array has any data. It is just a view for
accessing the buffer.

  --Toni

On Sat, Dec 4, 2010 at 1:12 AM, Paul Kinlan  wrote:
> I might have missed something but for appending client-side generated
> data to a blob can't you just append a UInt8Array as that is based off
> ArrayBuffer?
>
> I use it to generate zip files client side and attach them to an
> iframe so they are downloaded.
>
> P
> On Thursday, December 2, 2010, Toni Ruottu  wrote:
>> My code had a bug in it. The APIs seem to be working ok for my purposes.
>> Using the APIs, I was able to write Firefox's sendAsBinary method for chrome.
>> It is available from http://javascript0.org/wiki/Portable_sendAsBinary
>>
>>   --Toni
>>
>> On Tue, Nov 16, 2010 at 5:25 PM, Toni Ruottu  wrote:
>>> Sorry for slow answer. Took me a while to get on top of this. I think
>>> they just might answer my problem. However, I can not really tell
>>> before I see a working implementation. I wrote a test. See
>>> http://www.cs.helsinki.fi/u/twruottu/testi/bpost3.html It does not
>>> currently work with the latest development version of Chrome. I
>>> wonder, if I am doing something wrong.
>>>
>>>  --Toni
>>>
>>> On Wed, Oct 20, 2010 at 6:17 PM, Eric Uhrhane  wrote:
 Toni:

    BlobBuilder now has an append() method that takes an ArrayBuffer,
 and FileReader has readAsArrayBuffer.  Do these together satisfy your
 needs?

        Eric

 On Wed, Oct 20, 2010 at 3:39 AM, Toni Ruottu  wrote:
> I have discussed the topic before on some Chromium bug threads. I
> searched the archives of this mailing list for blobs and generated
> content, but was not too successful. There may be multiple different
> reasons why one would need to build blobs from generated data. The one
> that concerns me, is being able to do binary POSTs with XmlHTTPRequest
> in a standard manner. To send binary data over XHR one is required to
> send out a blob, but first the blob needs to be constructed with
> BlobBuilder. Let me fill you in on how I see the current situation.
> Maybe someone can spot an error in my line of thought.
>
> A new (empty) BlobBuilder is created by stating...
> var bb = new BlobBuilder();
>
> After creating a BlobBuilder, the user appends some data into the blob
> being generated by using the append function. The append function is
> overloaded and can be used to append multiple different types of data
> into the blob. Currently only existing blobs, and utf-8 text are
> supported.
>
> One can add an existing blob into the new one by doing...
> bb.append(existingBlob);
>
> One can add a text string in utf-8 format by doing...
> bb.append(aTextString);
>
> Once the data is in there, it is possible to construct the new blob 
> with...
> var blob = bb.getBlob()
>
> A blob has a slice method which makes it possible to turn a large blob
> into smaller ones. It is thus possible to cut out single bytes from a
> blob and use them construct new blobs by appending copies of these
> sample bytes together with the BlobBuilder.
>
> As sample bytes can only be generated by writing text into the blob as
> utf-8, it is not possible to generate all 8-bit patterns. More
> specifically, the bit patterns that are illegal in any given utf-8
> string, are not possible to generate using the current API. This leads
> developers into using various hacks to overcome the issue.
>
> For example one could ask the user to provide a file with sample
> bytes. Methods for reading a file into a blob are available, so there
> is no need to generate the sample bytes. There is however no way to
> make sure that the user provided a file with correct bit-patterns as
> the blob interface is to a large degree a read-only interface. A
> demonstration of using a file to overcome the issue is available at
> http://www.cs.helsinki.fi/u/twruottu/testi/bpost.html
>
> To solve the problem a third append function which accepts a list of
> integers, and adds the corresponding bytes into the blob is needed.
> Once such method has been introduced it should be possible to write
> the 7-bit ascii string "foo" into a BlobBuilder by doing...
> bb.append([102,111,111]);
>
> It should also be possible to add bytes 0x00 a
>
> --
> Paul Kinlan
> Developer Advocate @ Google for Chrome and HTML5
> t: +447730517944
> tw: @Paul_Kinlan 
> LinkedIn: http://uk.linkedin.com/in/paulkinlan
> Blog: http://paul.kinlan.me
> Skype: paul.kinlan
>

Re: continue as a reserved word and a conflict with IndexedDB

[Charles Pritchard]

Should the spec have notes referring to the fact that it requires ECMA5 
conformance or parse errors may result?


I'm bringing this up regarding backward compatibility, as reserved 
words, if not escaped, lead to parse errors.


Somewhat useful table:
http://kangax.github.com/es5-compat-table/

It seems for backward compatibility, sites containing IDB-code should 
wrap all code in something like:

[script type="application/ecmascript;version=5"]

Or be certain to escape their continue/delete method calls.

Again, it seems like that ought to be noted within the spec: afaik, this 
is the only active spec which

breaks syntax/parser compatibility in active browsers. (Am I wrong there?).

Further, the spec references ECMAScript 3rd edition. Shouldn't it 
reference the 5th edition, as these reserved words mean

es3 is deprecated/obsolete?

http://www.w3.org/TR/IndexedDB/


-Charles

On 12/6/2010 8:02 AM, Oliver Hunt wrote:
This should work fine in a nightly already, if it doesn't you need to 
file a bug.


--Oliver


On Dec 6, 2010, at 3:08 AM, Jeremy Orlow wrote:

I'm pretty sure this was discussed and that EMCA5 does make it 
possible to use continue as we do.  At least that's the conclusion we 
had with delete.  My guess is that the JavaScriptCore (WebKit's main 
JavaScript engine) parser needs to be changed.  If so, you should 
probably file a bug at webkit.org .


J

On Mon, Dec 6, 2010 at 2:27 AM, Charles Pritchard > wrote:


I just noticed that the cursor "continue" method in IndexedDB
runs afoul of the Safari js parser, with "continue" being a
reserved word.

Was there any discussion on this issue? Should there be? Should I
not worry about it, and use  cursor['continue'] instead of
cursor.continue() ?

-Charles

[eventsource] Some data re Server-sent Events LC

[Arthur Barstow]

Re event-source spec, a few weeks ago I: reviewed the Bug list, reviewed 
e-mails submitted to public-webapps re the Dec 2009 LC and compared the 
LC version with the latest ED. I did not review WHATWG Issues for this 
spec [Issues] because I didn't know it existed.


= Bugzilla: 4 bugs filed: 3 Fixed; 1 Invalid; see [Bugs]; resolutions 
look OK to me.


= Diff between 19-Dec-2009 LC version 1.106 and version 1.154 
(1-Nov-2010 ED) [Diff]


I think most of the changes can be viewed as Editorial or Bug Fixes. The 
following changes do stick out though and should be reviewed by the 
group - (see [Diff] for Line numbers):


1. v1.106 Line 309 and v1.154 Line 328 - new text is inserted in Section 
2. Although this section is normative, the new text is mostly 
informative. (Clarification)


2. v1.106 Line 367 and v1.154 Line 394 - a new step #4 is added to 
Section 4. of the ED but this text was previously in Section 5 (bug fix).


3. v1.106 Line 460 and v1.154 Line 490 - the diff includes 3 changes: 
the handling of HTTP responses 301, 302, 303 and 307 are merged into one 
paragraph (a good clarification); a non-normative Note was removed; the 
handling of 305 response is moved.


4. v1.106 Line 531 and v1.154 Line 557 - the first paragraph of Section 
7. has been changed to refer to Streams rather than bytes. (Seems like a 
reasonable bug fix.)


= Comments sent to public-webapps

1. From: Krzysztof Maczyński <198...@gmail.com>
Subject: LCWD comments
Date: Thu, 1 Jul 2010
http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0007.html

Hixie responded to Krzysztof but Krzysztof did not reply.

2. From: Julian Reschke 
Subject: Last-Event-ID in http://dev.w3.org/html5/eventsource/
Date: Tue, 02 Mar 2010
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0728.html

Maciej and Julian exchanged responses. In the e-mail in this thread, it 
appears Julian was satisfied with Maciej's reasoning:


http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0735.html

-Art Barstow

[Issues] http://www.whatwg.org/issues/

[Diff]
http://dev.w3.org/cvsweb/html5/eventsource/Overview.html.diff?r1=1.106&r2=1.154&f=h

[Bugs]
http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=Server-Sent+Events+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Re: Seeking status of Server-sent Events, Web Storage and Web Workers

[Arthur Barstow]

OK, so coming back to the what's next for these 3 LC documents question 
[Head]  ...


All of these specs have a Bugzilla component for issue and comment 
tracking, all are included in the WHATWG issue tracker at [Issues], all 
of the specs have changed since their LC was published and all of the 
specs had at least one comment submitted against the LC via public-webapps.


With respect to "does a spec need to return to LC or can it advance to 
Candidate?", Section 7.4.6 of W3C process says:


[[
http://www.w3.org/2005/10/Process-20051014/tr.html#return-to-wg

A technical report is returned to a Working Group for further work in 
either of the following situations:


1. The Working Group makes substantive changes 
 
to the technical report at any time after a Last Call announcement 
 and prior 
to Publication as a Recommendation 
, 
*except* when the changes involve the removal of features at risk 
 
identified in a Call for Implementations 
. In the case of 
substantive changes, the Working Group MUST republish the technical 
report as a Working Draft.

]]

Since Hixie is active on HTML, perhaps someone else is willing to pick 
one of these LCs and to review the issues, bugs, diffs, etc. and propose 
the next step . Any volunteers?


A few weeks ago, I reviewed the diffs, bugs and public-webapps comments 
for Server-sent Events and will send that data separately.


-Art Barstow

[Head] 
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0755.html

[Issues] http://www.whatwg.org/issues/
[Bugzilla] http://www.w3.org/Bugs/Public/query.cgi?format=advanced


On Nov/29/2010 4:21 PM, ext Ian Hickson wrote:

On Tue, 23 Nov 2010, Arthur Barstow wrote:

Ian - regarding the following specs that ended LC on June 30, do you
have some type of comment tracking document, like you did for XBL2
[XBL2-DoC]?

I do not believe I kept track of e-mail feedback, but the history of
feedback filed through Bugzilla is naturally available through Bugzilla.

HTH.

Re: continue as a reserved word and a conflict with IndexedDB

[Oliver Hunt]

This should work fine in a nightly already, if it doesn't you need to file a 
bug.

--Oliver


On Dec 6, 2010, at 3:08 AM, Jeremy Orlow wrote:

> I'm pretty sure this was discussed and that EMCA5 does make it possible to 
> use continue as we do.  At least that's the conclusion we had with delete.  
> My guess is that the JavaScriptCore (WebKit's main JavaScript engine) parser 
> needs to be changed.  If so, you should probably file a bug at webkit.org.
> 
> J
> 
> On Mon, Dec 6, 2010 at 2:27 AM, Charles Pritchard  wrote:
> I just noticed that the cursor "continue" method in IndexedDB runs afoul of 
> the Safari js parser, with "continue" being a reserved word.
> 
> Was there any discussion on this issue? Should there be? Should I not worry 
> about it, and use  cursor['continue'] instead of cursor.continue() ?
> 
> -Charles
> 
> 

Re: [File API] abort()

[Anne van Kesteren]

On Fri, 03 Dec 2010 16:43:00 +0100, Arun Ranganathan  
 wrote:

- Original Message -

Per http://dev.w3.org/2006/webapi/FileAPI/#abort invoking abort()
always
results in events getting dispatched. This is not what happens in e.g.
Gecko at the moment. When the state is EMPTY the method simply
returns.


To be clear, what is the behavior you are prescribing?  Chrome folks,  
what is the desired behavior for your implementation?


That when the state of the object is EMPTY the abort() method returns  
directly rather than dispatching a bunch of events as per the current  
specification. There are actually tests in the Mozilla repository that  
contradict the current specification.




The dispatching of events should probably also be defined in terms of
the event queue so it becomes more clear which are to be dispatched
synchronously, etc. Currently all those interactions are quite vague
in the File API specification.


OK, I agree that this could be better, and should be improved in a  
subsequent version (especially making clear synchronous dispatch).  If  
you could be more specific about your nits, that would help as well.


What do you mean with subsequent version?

What I am basically saying is that for the events that are clearly not  
dispatched synchronously (e.g. reading from a Blob is an asynchronous  
operation) the specification ought to define this in terms of the HTML5  
event loop model. Much like e.g. XMLHttpRequest and Web Workers do.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: continue as a reserved word and a conflict with IndexedDB

[Jeremy Orlow]

I'm pretty sure this was discussed and that EMCA5 does make it possible to
use continue as we do.  At least that's the conclusion we had with delete.
 My guess is that the JavaScriptCore (WebKit's main JavaScript engine)
parser needs to be changed.  If so, you should probably file a bug at
webkit.org.

J

On Mon, Dec 6, 2010 at 2:27 AM, Charles Pritchard  wrote:

> I just noticed that the cursor "continue" method in IndexedDB runs afoul of
> the Safari js parser, with "continue" being a reserved word.
>
> Was there any discussion on this issue? Should there be? Should I not worry
> about it, and use  cursor['continue'] instead of cursor.continue() ?
>
> -Charles
>
>