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

[Simon Pieters]

On Thu, 12 Apr 2012 22:11:38 +0200, Eric U  wrote:

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 remove that from File Writer, no?


Yes.  The next draft I publish will mark it deprecated, and it will
eventually go away.


Please just remove it from the spec directly. If implementors feel they  
want to keep it around for a while longer, that's up to them, but the spec  
should describe the end goal.


As for implementations, it's usually simpler to remove features earlier  
than to wait a while and hope it will be possible to remove it later. The  
longer a feature is exposed on the Web, the more content will end up  
relying on it.



 However, currently at least Gecko and WebKit
support BlobBuilder, and WebKit doesn't yet have the Blob constructor,
so it'll be a little while before it actually fades away.

That being said, we should be talking about making this addition to
Blob, not to BlobBuilder.


I thought we discussed long ago it should be removed in favor of a
constructable(sp?) Blob?



Could be.  Like I said, it's still in the editor's draft.



Blob with constructor is in http://dev.w3.org/2006/webapi/FileAPI/




Also, should it not accept just ArrayBufferView then as per
XMLHttpRequest?



Is there existing content depending on BlobBuilder and its  
ArrayBufferView

stuff?



I thought the idea was to not have BlobBuilder at all.



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



--
Simon Pieters
Opera Software

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

[Arun Ranganathan]

> On Thu, Apr 12, 2012 at 12:54 PM, Anne van Kesteren
>  wrote:
> > Eric, the plan is to remove that from File Writer, no?
> 
> Yes.  The next draft I publish will mark it deprecated, and it will
> eventually go away.  However, currently at least Gecko and WebKit
> support BlobBuilder, and WebKit doesn't yet have the Blob
> constructor,
> so it'll be a little while before it actually fades away.
> 
> That being said, we should be talking about making this addition to
> Blob, not to BlobBuilder.

I intend to add ArrayBufferView as a parameter to the Blob constructor .

-- A*

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

[Eric U]

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 remove that from File Writer, no?

Yes.  The next draft I publish will mark it deprecated, and it will
eventually go away.  However, currently at least Gecko and WebKit
support BlobBuilder, and WebKit doesn't yet have the Blob constructor,
so it'll be a little while before it actually fades away.

That being said, we should be talking about making this addition to
Blob, not to BlobBuilder.

>>> I thought we discussed long ago it should be removed in favor of a
>>> constructable(sp?) Blob?
>>
>>
>> Could be.  Like I said, it's still in the editor's draft.
>
>
> Blob with constructor is in http://dev.w3.org/2006/webapi/FileAPI/
>
>
>
>>> Also, should it not accept just ArrayBufferView then as per
>>> XMLHttpRequest?
>>
>>
>> Is there existing content depending on BlobBuilder and its ArrayBufferView
>> stuff?
>
>
> I thought the idea was to not have BlobBuilder at all.
>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/

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

[Anne van Kesteren]

On Thu, 12 Apr 2012 21:58:00 +0200, Boris Zbarsky  wrote:

On 4/12/12 3:54 PM, Anne van Kesteren wrote:

I thought the idea was to not have BlobBuilder at all.


Dunno.  Is there content depending on it?


Maybe some browser specific demos or content, it's not implemented by  
everyone:


  http://caniuse.com/#search=blobbuilder

We have specifically refrained from implementing it based on outcome of  
past discussions. If plans have suddenly changed that would be good to  
know.



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

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

[Boris Zbarsky]

On 4/12/12 3:54 PM, Anne van Kesteren wrote:

Blob with constructor is in http://dev.w3.org/2006/webapi/FileAPI/


Right.  I'd ended up at the File Writer spec.


I thought the idea was to not have BlobBuilder at all.


Dunno.  Is there content depending on it?

-Boris

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

[Anne van Kesteren]

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 remove that from File Writer, no?


I thought we discussed long ago it should be removed in favor of a  
constructable(sp?) Blob?


Could be.  Like I said, it's still in the editor's draft.


Blob with constructor is in http://dev.w3.org/2006/webapi/FileAPI/


Also, should it not accept just ArrayBufferView then as per  
XMLHttpRequest?


Is there existing content depending on BlobBuilder and its  
ArrayBufferView stuff?


I thought the idea was to not have BlobBuilder at all.


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

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

[Boris Zbarsky]

On 4/12/12 3:44 PM, Anne van Kesteren wrote:

On Thu, 12 Apr 2012 21:26:24 +0200, Boris Zbarsky  wrote:

This should make it easier to append limited views; appending the
.buffer is a footgun because it appends the whole buffer.


Why are we still discussing BlobBuilder?


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?  ;)



I thought we discussed long ago it should be removed in favor of a 
constructable(sp?) Blob?


Could be.  Like I said, it's still in the editor's draft.


Also, should it not accept just ArrayBufferView then as per XMLHttpRequest?


Is there existing content depending on BlobBuilder and its 
ArrayBufferView stuff?


-Boris

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

[Anne van Kesteren]

On Thu, 12 Apr 2012 21:26:24 +0200, Boris Zbarsky  wrote:
This should make it easier to append limited views; appending the  
.buffer is a footgun because it appends the whole buffer.


Why are we still discussing BlobBuilder? I thought we discussed long ago  
it should be removed in favor of a constructable(sp?) Blob? Also, should  
it not accept just ArrayBufferView then as per XMLHttpRequest?



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

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

[Boris Zbarsky]

This should make it easier to append limited views; appending the 
.buffer is a footgun because it appends the whole buffer.


-Boris

Re: Should send() be able to take an ArrayBufferView?

[Glenn Maynard]

On Thu, Apr 12, 2012 at 1:34 PM, Ian Hickson  wrote:

> On Wed, 11 Apr 2012, Glenn Maynard wrote:
> >
> > That's not really what happens, though.  WebSocket gives you an
> ArrayBuffer
> > if the source is an ArrayBuffer, and a Blob if the source was a Blob
>
> No, at the protocol level they are indistinguishable, and at the API
> level the receiver decides which to use.
>

The API level is the only thing we're discussing.  I see what's happening,
though.

-- 
Glenn Maynard

Re: Should send() be able to take an ArrayBufferView?

[Ian Hickson]

On Wed, 11 Apr 2012, Glenn Maynard wrote:
> 
> That's not really what happens, though.  WebSocket gives you an ArrayBuffer
> if the source is an ArrayBuffer, and a Blob if the source was a Blob

No, at the protocol level they are indistinguishable, and at the API 
level the receiver decides which to use.

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

[Bug 16715] New: IndexedDB: Spec nit in steps for evaluating key path

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16715

   Summary: IndexedDB: Spec nit in steps for evaluating key path
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: jsb...@chromium.org
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


4.7 step 1.2 says 

"If the result of the previous step was not a valid key path, then..."

This should read:

"If the result of the previous step was not a valid key, then..."

-- 
Configure bugmail: https://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 16714] New: IndexedDB: creating an object store with Array-type key path and key generator should be forbidden

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16714

   Summary: IndexedDB: creating an object store with Array-type
key path and key generator should be forbidden
   Product: WebAppsWG
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Indexed Database API
AssignedTo: dave.n...@w3.org
ReportedBy: jsb...@chromium.org
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Per discussion on the list, specifying both a key generator for an object store
(via autoIncrement: true) and a key path which is an Array (via keyPath: [...])
would lead to inconsistent keys. This should not be supported.

This spec change should cover it:

OLD: If the optionalParameters parameter is specified, and autoIncrement is set
to true, and the keyPath parameter is specified to the empty string, or
specified to an Array and one of the items is an empty string, this function
must throw a InvalidAccessError exception.

NEW: If the optionalParameters parameter is specified, and autoIncrement is set
to true, and the keyPath parameter is specified to the empty string, or
specified to an Array, this function must throw a InvalidAccessError exception.

-- 
Configure bugmail: https://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: IndexedDB: Key generators (autoIncrement) and Array-type key paths

[Joshua Bell]

On Wed, Apr 11, 2012 at 10:56 PM, Jonas Sicking  wrote:

> > NEW: If the optionalParameters parameter is specified,
> and autoIncrement is
> > set to true, and the keyPath parameter is specified to the empty string,
> or
> > specified to an Array, this function must throw
> > a InvalidAccessError exception.
>
> I thought that this was what the spec already said, but you are indeed
> correct. Yes, I think we should make exactly this change. I think this
> matches the Firefox implementation.
>
> > [1] SPEC NIT: 4.7 step 1.2 says "If the result of the previous step was
> not
> > a valid key path, then..." - presumable this should read "... was not a
> > valid key, then..."
>
> File a bug?


Yep, will do (for both of these)

IndexedDB user's feedback

[Alexander Abramov]

Hello

I ask you about some new functions in IndexedDB API, which
are extremely needed:
1. How much space available for adding
2. Request user for more space
As I know now limit for IndexedDB in most browsers is about 50 Mb, but it
is not possible to know how much space used, so how much place still.
Adding this functions would be extremely useful.

Regards,
Alex Abramov

Reminder: RfC: LCWD of Widget Updates; deadline April 19

[Arthur Barstow]

 Original Message 
Subject:RfC: LCWD of Widget Updates; deadline April 19
Resent-Date:Thu, 22 Mar 2012 16:49:25 +
Resent-From:
Date:   Thu, 22 Mar 2012 12:48:37 -0400
From:   ext Arthur Barstow 
Reply-To:   public-webapps 
To: public-webapps 



[ bcc public-native-web-apps ]

On March 23, WebApps published a LCWD of Widget Updates
.

If you have any comments, please send them to public-webapps@w3.org by
April 19.

Re: Speech API: first editor's draft posted

[Hans Wennborg]

On Thu, Apr 12, 2012 at 10:30, Hans Wennborg  wrote:
> We welcome discussion and feedback on this editor's draft. Please send
> your comments to the public-speech-api-cont...@w3.org mailing list.

Correction: please send your comments to the public-speech-...@w3.org
mailing list.

Hans Wennborg

Speech API: first editor's draft posted

[Hans Wennborg]

In December, Google proposed [1] to public-webapps a Speech JavaScript
API that subset supports the majority of the use-cases in the Speech
Incubator Group's Final Report. This proposal provides a programmatic
API that enables web-pages to synthesize speech output and to use
speech recognition as an input for forms, continuous dictation and
control.

We have now posted in the Speech-API Community Group's repository, a
slightly updated proposal [2], the differences include:

 - Document is now self-contained, rather than having multiple
references to the XG Final Report.
 - Renamed SpeechReco interface to SpeechRecognition
 - Renamed interfaces and attributes beginning SpeechInput* to
SpeechRecognition*
 - Moved EventTarget to constructor of SpeechRecognition
 - Clarified that grammars and lang are attributes of SpeechRecognition
 - Clarified that if index is greater than or equal to length, returns null

We welcome discussion and feedback on this editor's draft. Please send
your comments to the public-speech-api-cont...@w3.org mailing list.

Glen Shires
Hans Wennborg

[1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html
[2] http://dvcs.w3.org/hg/speech-api/raw-file/tip/speechapi.html

[Bug 16708] s/ArrayBuffer/ArrayBufferView/ - See http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0177.html

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16708

Simon Pieters  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|other Hixie drafts (editor: |WebSocket API (editor: Ian
   |Ian Hickson)|Hickson)
Product|HTML WG |WebAppsWG
  QAContact|public-html-bugzi...@w3.org |public-webapps-bugzilla@w3.
   ||org

-- 
Configure bugmail: https://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 16303] meaning of "all" charset parameters of content-type header

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16303

Anne  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WORKSFORME

--- Comment #4 from Anne  2012-04-12 07:16:27 UTC ---
Oh please. We're not going to open bugs for everything where implementations
currently mismatch.

-- 
Configure bugmail: https://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: [XHR2] undefined as user/password arguments

[Jonas Sicking]

On Thu, Apr 12, 2012 at 12:08 AM, Anne van Kesteren  wrote:
> On Wed, 11 Apr 2012 12:57:23 +0200, Jonas Sicking  wrote:
>>
>> Apologies if this has been discussed before and I missed it, or have
>> forgotten about it.
>
>
> It has been discussed before. I think last time this came up I was wondering
> why we needed these various options for what to do with undefined and then
> there is ES6 as well:
> http://lists.w3.org/Archives/Public/public-script-coord/2012AprJun/0105.html

Well, there's the generic discussion regarding how undefined and
optional work together in ES6/WebIDL.

But then there's a separate discussion about what's required for web
compatibility in XHR.

The outcome of the first discussion might very well affect the IDL for
what we use in the spec. But the behavior we need for web compat is
not really affected by how optional arguments are defined by
ES6/WebIDL.

> I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16707 to make sure we
> do not forget about this.

Thanks!

> Also, there's no XHR2.

Sorry, my bookmark still said XHR2.

/ Jonas

[Bug 16303] meaning of "all" charset parameters of content-type header

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16303

Julian Reschke  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |

--- Comment #3 from Julian Reschke  2012-04-12 07:13:26 
UTC ---
I believe this should be left open until you have evidence of at least two
implementations doing what the spec asks for.

-- 
Configure bugmail: https://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: [XHR2] undefined as user/password arguments

[Anne van Kesteren]

On Wed, 11 Apr 2012 18:43:20 +0200, Boris Zbarsky  wrote:

On 4/11/12 12:26 PM, Boris Zbarsky wrote:

That's not correct. For nullable types, ES undefined is converted to IDL
null per step 3 of
. There's some
extra complexity there around DOMString in step 1, but it only applies
when [TreatUndefinedAs] is used, which it's not in this case.


Though the current prose talks about "if the arguent was not omitted",  
so treats null and undefined the same: as the argument being specified.  
  That seems buggy for the exact reasons Jonas lists.


What would make sense here is to either use [TreatUndefinedAs=Missing]  
(and condition the "no user or password" behavior off the IDL value  
being unspecified) or to give these things a default null value and  
condition the "no user or password" behavior off the IDL value being  
null.


The question that should decide us between those two options is whether  
passing null should be treated like something is set or not here.


The user/password area is a bit of a mess because of  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10326 and to a lesser  
extent https://www.w3.org/Bugs/Public/show_bug.cgi?id=15418 If someone  
could explain what we should do here that would be nice.



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

[Bug 16707] New: user/password set to undefined means missing

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16707

   Summary: user/password set to undefined means missing
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: XHR
AssignedTo: ann...@opera.com
ReportedBy: ann...@opera.com
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


When the user/password arguments are set to undefined they should be treated as
missing arguments. Either via an IDL option or because that is what undefined
means per ES/IDL.

-- 
Configure bugmail: https://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: [XHR2] undefined as user/password arguments

[Anne van Kesteren]

On Wed, 11 Apr 2012 12:57:23 +0200, Jonas Sicking  wrote:

Apologies if this has been discussed before and I missed it, or have
forgotten about it.


It has been discussed before. I think last time this came up I was  
wondering why we needed these various options for what to do with  
undefined and then there is ES6 as well:  
http://lists.w3.org/Archives/Public/public-script-coord/2012AprJun/0105.html


I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=16707 to make sure  
we do not forget about this.


Also, there's no XHR2.


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

Re: Should send() be able to take an ArrayBufferView?

[Anne van Kesteren]

On Wed, 11 Apr 2012 22:06:07 +0200, Glenn Maynard  wrote:
I might argue that we shouldn't have ArrayBuffer entry points at all;  
just ArrayBufferView.  It's trivial to create a view on the whole of an

ArrayBuffer, and this is leading towards us having two separate entry
points for every single API that accepts typed arrays.


I went with this design.

http://dvcs.w3.org/hg/xhr/rev/f0c81ac5c134


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