date:20120411

On Wed, Apr 11, 2012 at 4:47 PM, Joshua Bell  wrote:
> Something I'm not seeing covered by the spec - what should the behavior be
> when inserting a value into an object store if the object store has a key
> generator and the key path is an Array? Should this be supported, or is it
> an error?
...
> If we want to prevent this, the spec change would be:
>
> 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.

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?

/ Jonas

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

On Wed, Apr 11, 2012 at 8:15 PM, Boris Zbarsky  wrote:

> On 4/11/12 5:54 PM, Charles Pritchard wrote:
>
>> Note that those have different performance characteristics, too; the
>>> latter involves a buffer copy.
>>>
>>
>> Are we stuck with a buffer copy (or copy on write) mechanism anyway?
>>
>
> Yes-ish; the question is how many copies there are.

Well, that's a big "or".  If your ArrayBuffer implementation supports COW,
then in most cases you can avoid making any copies at all (well, until it
reaches the network layer).  If it doesn't, you're probably stuck with at
least one copy when send() is made.  (But, as you said, if you don't have
COW and you have to create a new ArrayBuffer, then you're looking at one
*more* extra copy either way.)

On Wed, Apr 11, 2012 at 8:21 PM, Jarred Nicholls  wrote:

> I haven't really either, but if there were some peer-to-peer support,
>> then the receiving peer should still get an ArrayBuffer even if the
>> sender sent an ArrayBufferView.
>>
>
>
> Yes, this is the only approach that would make sense to me.  The receiver
> is just getting a dump of bytes and can consume them however it sees fit.
>  The view makes no difference here.
>

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, even
though both are really just a bundle of bytes.  That's surprising to me; my
first impression is the receiver should say which one it wants, as with how
XHR works.  (I havn't used WebSocket in practice, though, so take that
first impression with a grain of salt.)

-- 
Glenn Maynard

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

2012-04-11 Thread Jarred Nicholls

On Wed, Apr 11, 2012 at 5:54 PM, Kenneth Russell  wrote:

> On Wed, Apr 11, 2012 at 2:48 PM, Boris Zbarsky  wrote:
> > On 4/11/12 5:41 PM, Kenneth Russell wrote:
> >>
> >> Sending an ArrayBufferView would still have to use "arraybuffer" as
> >> the type of data. I don't think it would be a good idea to try to
> >> instantiate the same subclass of ArrayBufferView on the receiving
> >> side.
> >
> >
> > I'm not sure what this means...
>
> What I mean is that if somehow a browser were on the receiving end of
> one of these messages, the type of the incoming message should still
> be "arraybuffer".
>
> > For XHR.send(), sending an ArrayBufferView should take the byte array
> that
> > the ArrayBufferView is mapping, and send that.  It's possible to achieve
> the
> > same thing now with some hoop jumping involving a possible buffer copy;
> I'm
> > just saying we should remove the need for that hoop jumping.
>
> Agree that these should be the semantics.
>
> > I haven't looked at WebSocket in enough detail to comment intelligently
> on
> > it.
>
> I haven't really either, but if there were some peer-to-peer support,
> then the receiving peer should still get an ArrayBuffer even if the
> sender sent an ArrayBufferView.
>

Yes, this is the only approach that would make sense to me.  The receiver
is just getting a dump of bytes and can consume them however it sees fit.
 The view makes no difference here.


>
> -Ken
>
>

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


On 4/11/12 5:54 PM, Kenneth Russell wrote:

I haven't looked at WebSocket in enough detail to comment intelligently on
it.


I haven't really either, but if there were some peer-to-peer support,
then the receiving peer should still get an ArrayBuffer even if the
sender sent an ArrayBufferView.


That would make sense to me, yes.  The receiver is just getting a byte 
array with no structure imposed on it, no matter where those bytes came 
from.


-Boris

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


On 4/11/12 5:54 PM, Charles Pritchard wrote:

Note that those have different performance characteristics, too; the
latter involves a buffer copy.


Are we stuck with a buffer copy (or copy on write) mechanism anyway?


Yes-ish; the question is how many copies there are.


What is the spec on changing the buffer after xhr.send?


http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#the-send%28%29-method 
says that the request body is the data in the array buffer when send() 
is called.


Whether that involves a copy depend on whether you get the data down to 
the socket before send() returns, obviously.  In most cases, I would 
assume it would.


Having so slice() means you have to copy twice instead of once.

-Boris

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

On Wed, Apr 11, 2012 at 7:19 PM, Kenneth Russell  wrote:

> On Wed, Apr 11, 2012 at 5:05 PM, Glenn Maynard  wrote:
> > (I don't think there's any particular reason for ArrayBuffer to be
> opaque.
> > It would have been nice if ArrayBuffer acted like an Int8Array, so you
> can
> > access the contents as an array of bytes without an extra step.)
>
> That's the way Java's New I/O API worked and it caused asymmetries in
> the API. I believe it was Chris Marrin who originally proposed
> factoring out the storage into ArrayBuffer and that has worked out
> very nicely. For example, ArrayBuffer is the only Transferable
> interface in the spec, and all of the view types are equal peers in
> the spec.
>

Java isn't known for well-designed APIs.  Just because a Java API does
something badly doesn't mean it can't be done well; there's no reason that
supporting 8-bit access to an ArrayBuffer would cause asymmetries.

For example, a reasonable API might be:

class ArrayBufferView; // buffer, byteOffset, byteLength
class ArrayBuffer: ArrayBufferView; // buffer points to itself; byteOffset
is always 0; provides Int8Array access
class Int16Array: ArrayBufferView;

which allows ArrayBuffer to be used directly, eliminates most of the
unnecessary differences between ArrayBuffer and array views, and allows
APIs like XHR2 to simply accept ArrayBufferView and work on everything,
instead of having separate ArrayBuffer and ArrayBufferView overloads.  It's
a much simpler API.

(This could almost be done today with a good chance of not breaking
existing code.  Unfortunately, the TypedArray(TypedArray) vs.
TypedArray(ArrayBuffer) constructors probably make it not possible, since
the former makes a copy and the latter doesn't.  That's an unfortunate
inconsistency in and of itself...)

-- 
Glenn Maynard

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

On Wed, Apr 11, 2012 at 5:05 PM, Glenn Maynard  wrote:
> (I don't think there's any particular reason for ArrayBuffer to be opaque.
> It would have been nice if ArrayBuffer acted like an Int8Array, so you can
> access the contents as an array of bytes without an extra step.)

That's the way Java's New I/O API worked and it caused asymmetries in
the API. I believe it was Chris Marrin who originally proposed
factoring out the storage into ArrayBuffer and that has worked out
very nicely. For example, ArrayBuffer is the only Transferable
interface in the spec, and all of the view types are equal peers in
the spec.

> It sounds like you're referring to structured clone here, rather than XHR?
> I think that you should be able to structured clone a view, and the result
> should be the same view type, attached to a newly-created ArrayBuffer.  If a
> structured clone operation sends multiple views that are from the same
> ArrayBuffer, it also seems like the result should be views on the same new
> ArrayBuffer.

I'm essentially referring to a hypothetical use case of peer-to-peer
communication over WebSockets. My point is only that the incoming
binary data type should continue to be "arraybuffer" in both XHR and
WebSockets. If one end of a WebSocket sent an ArrayBufferView, the
other end should still receive an ArrayBuffer.

Regarding structured clone, it works in exactly the way you state
above. I'm not proposing any changes to those semantics.

>  (I'm not sure about the details, though, eg. what happens if
> you have a 10 MB ArrayBuffer, and you send two Int8Arrays which are views on
> the first and last bytes?  Is the new ArrayBuffer "packed", with the unused
> parts of the array removed?  This would need some thought.)

No, compacting the ArrayBuffer behind the scenes could break
applications. The new ArrayBuffer would need to contain all of the
original data. For highest performance the application could put the
ArrayBuffer into the Transferable array.

-Ken

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

On Wed, Apr 11, 2012 at 3:40 PM, Charles Pritchard  wrote:

>  I know you've been circling this issue for awhile, so I'll put it out
> there again: yes, using typed arrays is difficult.
>

Typed arrays have a few gotchas, and design decisions that I disagree with,
but I wouldn't call them difficult.

On Wed, Apr 11, 2012 at 4:41 PM, Kenneth Russell  wrote:

> ArrayBufferView implies knowledge of the type of data being pointed to.

Not *strictly*.  If you don't care about the type of the underlying data,
then you can simply use Int8Array to represent it.  This is the case with
XHR, where you're just sending the memory buffer verbatim.

In principle, we could have "UntypedView" or something to create a view on
ArrayBuffer without implying anything about the type, but I don't think
that really wins us anything useful.

The reason XHR, WebSocket and other APIs refer only to ArrayBuffer is
> probably to insulate them from changes in the typed array
> specification.

I suspect this is actually just an oversight.  (Anne?)

> It seems that there is general agreement that the
> ArrayBuffer concept, of a completely opaque in-memory data container,
> is useful.

(I don't think there's any particular reason for ArrayBuffer to be opaque.
It would have been nice if ArrayBuffer acted like an Int8Array, so you can
access the contents as an array of bytes without an extra step.)

It's clear that there is some disagreement with some of the
> other design decisions of the typed array specification, which might
> motivate leaving only the ArrayBuffer overload for the time being.
>

I've mentioned some of my issues with it, but it's already implemented and
used in the wild, so there won't be any fundamental (incompatible)
changes.  So, there's no particular reason to avoid supporting views.

Sending an ArrayBufferView would still have to use "arraybuffer" as
> the type of data. I don't think it would be a good idea to try to
> instantiate the same subclass of ArrayBufferView on the receiving
> side.
>

It sounds like you're referring to structured clone here, rather than XHR?
I think that you should be able to structured clone a view, and the result
should be the same view type, attached to a newly-created ArrayBuffer.  If
a structured clone operation sends multiple views that are from the same
ArrayBuffer, it also seems like the result should be views on the same new
ArrayBuffer.  (I'm not sure about the details, though, eg. what happens if
you have a 10 MB ArrayBuffer, and you send two Int8Arrays which are views
on the first and last bytes?  Is the new ArrayBuffer "packed", with the
unused parts of the array removed?  This would need some thought.)

-- 
Glenn Maynard

IndexedDB: Key generators (autoIncrement) and Array-type key paths

2012-04-11 Thread Joshua Bell

Something I'm not seeing covered by the spec - what should the behavior be
when inserting a value into an object store if the object store has a key
generator and the key path is an Array? Should this be supported, or is it
an error?

e.g. what is alerted:

var store = db.createObjectStore('store', { keyPath: ['id1', 'id2'],
autoIncrement: true });
store.put({name: 'Alice'});
store.count().onsuccess = function (e) {
alert(JSON.stringify(e.target.result)); };
store.openCursor().onsuccess = function (e) {
  var cursor = e.target.result;
  if (cursor) {
alert(JSON.stringify(e.target.result.value));
cursor.continue();
  }
};

I can imagine multiple outcomes:

1 then {"name": "Alice", "id1": 1}
1 then {"name": "Alice", "id1": 1, "id2": 1}
2 then {"name": "Alice", "id1": 1, "id2": 2} then {"name": "Alice", "id1":
1, "id2": 2}

But in none of these cases does evaluating the key path against the value
match the key. Therefore, I suspect this scenario should not be supported.

My reading of the spec:

3.2.4 "Database" / "createObjectStore" ... If keyPath is an Array, then
each item in the array is converted to a string. ... If ...
autoIncrement is set to true, and the keyPath parameter is ... specified to
an Array ...

So Array-type key paths are not explicitly ruled out on object stores; nor
is there a specific clause forbidding autoIncrement + Array-type key paths.

3.2.5 "Object Store" / "put" - an error should be thrown if ... The object
store uses in-line keys and the result of evaluating the object store's key
path yields a value and that value is not a valid key.

4.7 "steps for extracting a key from a value using a key
path"  If keyPath is an Array, then ... For each item in the keyPath Array
... Evaluate ... If the result of the previous step was not a valid key
path[1], then abort the overall algorithm and no value is returned.

So, in the example given, the put() is not prevented - the key path would
yield no value, which is fine.

5.1 "steps for storing a record into an object store" step 2: If store uses
a key generator and key is undefined, set key to the next generated key.
If store also uses in-line keys, then set the property invalue pointed to
by store's key path to the new value for key, as shown in the steps to
assign a key to a value using a key path.

4.13 "steps to assign a key to a value using a key path" is written
assuming the keyPath is a string.

So, by my reading something between 5.1 and 4.13 needs to be clarified if
this should be supported.

If we want to prevent this, the spec change would be:

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.

[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..."

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

On Wed, Apr 11, 2012 at 2:48 PM, Boris Zbarsky  wrote:
> On 4/11/12 5:41 PM, Kenneth Russell wrote:
>>
>> Sending an ArrayBufferView would still have to use "arraybuffer" as
>> the type of data. I don't think it would be a good idea to try to
>> instantiate the same subclass of ArrayBufferView on the receiving
>> side.
>
>
> I'm not sure what this means...

What I mean is that if somehow a browser were on the receiving end of
one of these messages, the type of the incoming message should still
be "arraybuffer".

> For XHR.send(), sending an ArrayBufferView should take the byte array that
> the ArrayBufferView is mapping, and send that.  It's possible to achieve the
> same thing now with some hoop jumping involving a possible buffer copy; I'm
> just saying we should remove the need for that hoop jumping.

Agree that these should be the semantics.

> I haven't looked at WebSocket in enough detail to comment intelligently on
> it.

I haven't really either, but if there were some peer-to-peer support,
then the receiving peer should still get an ArrayBuffer even if the
sender sent an ArrayBufferView.

-Ken

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

On 4/11/2012 2:50 PM, Boris Zbarsky wrote:

On 4/11/12 5:47 PM, Charles Pritchard wrote:

On 4/11/2012 2:41 PM, Kenneth Russell wrote:
On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky 
wrote:

> Seems like right now passing a typed array to send() requires a bit
of extra
> hoop-jumping to pass the .buffer instead, right? Is that desirable?

It may be convenient to add an overload to send() (presumably on both
XHR and WebSocket? Any others?) accepting ArrayBufferView. As pointed

It's convenient.

xhr.send(view); // shorthand
xhr.send(view.buffer.slice(view.byteOffset,
view.byteOffset+view.byteLength)); // longhand.

Note that those have different performance characteristics, too; the 
latter involves a buffer copy.

Are we stuck with a buffer copy (or copy on write) mechanism anyway?

What is the spec on changing the buffer after xhr.send?

example:
xhr.send(bigView.buffer); bigView[0] = 255; bigView[1000] = 255;

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

On 4/11/12 5:47 PM, Charles Pritchard wrote:

On 4/11/2012 2:41 PM, Kenneth Russell wrote:

On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky wrote:

> Seems like right now passing a typed array to send() requires a bit
of extra
> hoop-jumping to pass the .buffer instead, right? Is that desirable?

It may be convenient to add an overload to send() (presumably on both
XHR and WebSocket? Any others?) accepting ArrayBufferView. As pointed

It's convenient.

xhr.send(view); // shorthand
xhr.send(view.buffer.slice(view.byteOffset,
view.byteOffset+view.byteLength)); // longhand.

Note that those have different performance characteristics, too; the 
latter involves a buffer copy.

Boris, How do we feature test for support of the shorthand method?

  try {
XHR.send(view);
  } catch (e) {
// No support for sending ArrayBufferView; fall back to complicated
// slow stuff
  }

I assume you're already feature-testing just like that for ArrayBuffer 
support; if you're not, then just doing whatever testing you do for 
ArrayBuffer should work.  ;)

-Boris

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

On Wed, Apr 11, 2012 at 2:47 PM, Charles Pritchard  wrote:
> On 4/11/2012 2:41 PM, Kenneth Russell wrote:
>>
>> On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky  wrote:
>>>
>>> >  Seems like right now passing a typed array to send() requires a bit of
>>> > extra
>>> >  hoop-jumping to pass the .buffer instead, right?  Is that desirable?
>>
>> It may be convenient to add an overload to send() (presumably on both
>> XHR and WebSocket? Any others?) accepting ArrayBufferView. As pointed
>
>
> It's convenient.
>
> xhr.send(view); // shorthand
> xhr.send(view.buffer.slice(view.byteOffset,
> view.byteOffset+view.byteLength)); // longhand.
>
> Kenneth,
>
> Can we get a voice from MS? They've been supporting typed arrays in IE10 for
> awhile.
> If we're going to have this method, I'd really like to see it in IE10.

I have no control over that -- I believe there are representatives
from Microsoft that monitor this list and hope they will voice an
opinion.

-Ken


> Boris, How do we feature test for support of the shorthand method?
>
>
> -Charles
>

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


On 4/11/12 5:41 PM, Kenneth Russell wrote:

Sending an ArrayBufferView would still have to use "arraybuffer" as
the type of data. I don't think it would be a good idea to try to
instantiate the same subclass of ArrayBufferView on the receiving
side.


I'm not sure what this means...

For XHR.send(), sending an ArrayBufferView should take the byte array 
that the ArrayBufferView is mapping, and send that.  It's possible to 
achieve the same thing now with some hoop jumping involving a possible 
buffer copy; I'm just saying we should remove the need for that hoop 
jumping.


I haven't looked at WebSocket in enough detail to comment intelligently 
on it.


-Boris

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

On 4/11/2012 2:41 PM, Kenneth Russell wrote:

On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky  wrote:

>  Seems like right now passing a typed array to send() requires a bit of extra
>  hoop-jumping to pass the .buffer instead, right?  Is that desirable?

It may be convenient to add an overload to send() (presumably on both
XHR and WebSocket? Any others?) accepting ArrayBufferView. As pointed

It's convenient.

xhr.send(view); // shorthand
xhr.send(view.buffer.slice(view.byteOffset, 
view.byteOffset+view.byteLength)); // longhand.

Kenneth,

Can we get a voice from MS? They've been supporting typed arrays in IE10 
for awhile.

If we're going to have this method, I'd really like to see it in IE10.

Boris, How do we feature test for support of the shorthand method?

-Charles

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


On 4/11/12 5:28 PM, Charles Pritchard wrote:

Adding .send(ArrayBufferView) doesn't seem like it'd hurt anything; it
would help in the case of subarray.


OK, we agree that far.  ;)


Removing .send(ArrayBuffer) would hurt things.


That seems plausible.  I'm more interested in the addition than the removal.


It may cut down on constructors/header code within cpp implementations.


Not sure what you mean.


As an author, I'm going to be stuck to .send(ArrayBuffer) for awhile,
given the distance between this proposal and pick-up by MS and Apple.


MS doesn't support ArrayBuffer at all, last I checked.  They plan to add 
support in IE10.  If we make this change soonish, they might ship 
support for send(ArrayBufferView) in IE10 as well.


I'd love some actual feedback on that from the Microsoft reps in the 
group...



Again, if there's anything happening with TC39 that would make
.send(BinaryData) available, I'm up for waiting on it, instead of jumping
in early with ArrayBufferView.


Why?  The two things seem to be completely orthogonal.  There's no 
reason we can't do both.


-Boris

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

On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky  wrote:
> Seems like right now passing a typed array to send() requires a bit of extra
> hoop-jumping to pass the .buffer instead, right?  Is that desirable?

It may be convenient to add an overload to send() (presumably on both
XHR and WebSocket? Any others?) accepting ArrayBufferView. As pointed
out elsewhere in this thread, ArrayBufferViews are a lightweight
mechanism to refer to a sub-portion of an ArrayBuffer. All of the
WebGL APIs which accept ArrayBuffer also accept ArrayBufferView,
though the converse is not true. ArrayBufferView implies knowledge of
the type of data being pointed to. In WebGL, some APIs accept only
certain subclasses of ArrayBufferView, depending on other arguments to
the function (readPixels, texImage2D, etc.).

The reason XHR, WebSocket and other APIs refer only to ArrayBuffer is
probably to insulate them from changes in the typed array
specification. It seems that there is general agreement that the
ArrayBuffer concept, of a completely opaque in-memory data container,
is useful. It's clear that there is some disagreement with some of the
other design decisions of the typed array specification, which might
motivate leaving only the ArrayBuffer overload for the time being.

Sending an ArrayBufferView would still have to use "arraybuffer" as
the type of data. I don't think it would be a good idea to try to
instantiate the same subclass of ArrayBufferView on the receiving
side.

-Ken

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


On 4/11/2012 1:16 PM, Boris Zbarsky wrote:

On 4/11/12 4:06 PM, Glenn Maynard wrote:

It's a bit worse than that, actually: if you want to send only part of a
buffer, you have to create a whole new ArrayBuffer and copy the data
over.  If you just pass "view.buffer", you'll send the *whole*
underlying buffer, not just the slice represented by the view.


Oh, that's just broken.

That argues for the removal of the ArrayBuffer overload, indeed, and 
just leaving the ArrayBufferView version.




Adding .send(ArrayBufferView) doesn't seem like it'd hurt anything; it 
would help in the case of subarray.

Removing .send(ArrayBuffer) would hurt things.

I'd imagine that we saw send(ArrayBuffer) first because that's just how 
the semantics for ArrayBuffer have been used.


It may cut down on constructors/header code within cpp implementations.


As an author, I'm going to be stuck to .send(ArrayBuffer) for awhile, 
given the distance between this proposal and pick-up by MS and Apple.


Again, if there's anything happening with TC39 that would make 
.send(BinaryData) available, I'm up for waiting on it, instead of jumping

in early with ArrayBufferView.


-Charles

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

On 4/11/12 5:04 PM, Charles Pritchard wrote:

When/if we start using the "Binary Data" instead of re-purposing typed
arrays.

Then we'll need to add more send() overloads, probably. What those
overloads will be, exactly, depends on the final state of the Binary
Data spec. I don't see the problem, honestly.

postMessage does arbitrary object graphs, which can include either
ArrayBuffers or ArrayBufferViews. If you try to postMessage a typed
array, the receiver will get a typed array, as expected.

My understanding is/was that an ArrayBufferView will be copied whereas
an ArrayBuffer will be neutered/transferred.

This understanding is incorrect, as stated.

The only things that are transferred are the ones listed in the
sequence argument.

If you don't list anything there,
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#structured-clone
will be run on everything. This will call into
http://www.khronos.org/registry/typedarray/specs/latest/#9.3 and then
http://www.khronos.org/registry/typedarray/specs/latest/#9.1 and copy
all the various ArrayBufferViews and ArrayBuffers.

You can't list an ArrayBufferView in the trasferable list.

You _can_ list an ArrayBufer in the transferable list; if that's the
case it will be neutered and transferred. If there are ArrayBufferViews
being cloned that reference this ArrayBuffer, the clones will reference
the transferred buffer.

These practices are already established. You're exploring ways to make
using them easier.

Passing typed arrays to send() can't possibly be "established" since
it's not exactly supported very well across browsers (and is disallowed
by the spec at the moment).

Typed Arrays have matured.

So? I'm not proposing changing anything about typed arrays. I'm
proposing expanding the set of things that can be passed to send().

They're available in all major implementations

They're not available in any shipping IE version, last I checked.

I know they can be a pain in the ass, but they are functioning.

That has nothing to do with the arguments allowed for XHR.send().

-Boris

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


On 4/11/2012 1:49 PM, Boris Zbarsky wrote:

On 4/11/12 4:40 PM, Charles Pritchard wrote:

That argues for the removal of the ArrayBuffer overload, indeed, and
just leaving the ArrayBufferView version.


I've got no idea where TC39 is taking things.


ArrayBuffer and ArrayBufferView and such are not specced in TC39 at 
the moment, and I'm not aware of plans to change that (though there 
are other plans like Binary Data that are related).



I think that's the bigger issue here.


How so?


If ArrayBufferView becomes a JS semantic, some of this is moot


Which part?


When/if we start using the "Binary Data" instead of re-purposing typed 
arrays.



All of the postMessage semantics use ArrayBuffer AFAIK.

postMessage does arbitrary object graphs, which can include either 
ArrayBuffers or ArrayBufferViews.  If you try to postMessage a typed 
array, the receiver will get a typed array, as expected.


My understanding is/was that an ArrayBufferView will be copied whereas 
an ArrayBuffer will be neutered/transferred.





I know you've been circling this issue for awhile, so I'll put it out
there again: yes, using typed arrays is difficult.


Sure, but we shouldn't make it _more_ difficult if we can avoid it.


These practices are already established. You're exploring ways to make 
using them easier.


Typed Arrays have matured. They're available in all major 
implementations and as far as I'm aware, compatible across the 
implementations.


I know they can be a pain in the ass, but they are functioning.

-Charles

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


On 4/11/12 4:40 PM, Charles Pritchard wrote:

That argues for the removal of the ArrayBuffer overload, indeed, and
just leaving the ArrayBufferView version.


I've got no idea where TC39 is taking things.


ArrayBuffer and ArrayBufferView and such are not specced in TC39 at the 
moment, and I'm not aware of plans to change that (though there are 
other plans like Binary Data that are related).



I think that's the bigger issue here.


How so?


If ArrayBufferView becomes a JS semantic, some of this is moot


Which part?


All of the postMessage semantics use ArrayBuffer AFAIK.


postMessage does arbitrary object graphs, which can include either 
ArrayBuffers or ArrayBufferViews.  If you try to postMessage a typed 
array, the receiver will get a typed array, as expected.



I know you've been circling this issue for awhile, so I'll put it out
there again: yes, using typed arrays is difficult.


Sure, but we shouldn't make it _more_ difficult if we can avoid it.

-Boris

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


On 4/11/2012 1:16 PM, Boris Zbarsky wrote:

On 4/11/12 4:06 PM, Glenn Maynard wrote:

It's a bit worse than that, actually: if you want to send only part of a
buffer, you have to create a whole new ArrayBuffer and copy the data
over.  If you just pass "view.buffer", you'll send the *whole*
underlying buffer, not just the slice represented by the view.


Oh, that's just broken.

That argues for the removal of the ArrayBuffer overload, indeed, and 
just leaving the ArrayBufferView version.


I've got no idea where TC39 is taking things. I think that's the bigger 
issue here.
Yes, I've been bitten by trying to use .subarray  instead of .slice (as 
Glenn points out).


If ArrayBufferView becomes a JS semantic, some of this is moot; and 
ArrayBuffer is still very necessary for compatibility.


All of the postMessage semantics use ArrayBuffer AFAIK.


I know you've been circling this issue for awhile, so I'll put it out 
there again: yes, using typed arrays is difficult.



-Charles

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


On 4/11/12 4:06 PM, Glenn Maynard wrote:

It's a bit worse than that, actually: if you want to send only part of a
buffer, you have to create a whole new ArrayBuffer and copy the data
over.  If you just pass "view.buffer", you'll send the *whole*
underlying buffer, not just the slice represented by the view.


Oh, that's just broken.

That argues for the removal of the ArrayBuffer overload, indeed, and 
just leaving the ArrayBufferView version.


-Boris

[Bug 16703] New: I am suggesting a default value for the "code" argument to the close method. I am currently experimenting with this method and noticed that Chrome and Firefox seem to use different

2012-04-11 Thread bugzilla

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

   Summary: I am suggesting a default value for the "code"
argument to the close method.  I am currently
experimenting with this method and noticed that Chrome
and Firefox seem to use different default values.  If
I do not specify a code, Chrome appears to use 1005 (
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/websockets/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
I am suggesting a default value for the "code" argument to the close method. 
I am currently experimenting with this method and noticed that Chrome and
Firefox seem to use different default values.  If I do not specify a code,
Chrome appears to use 1005 (CLOSE_NO_STATUS), while Firefox appears to use
1000 (CLOSE_NORMAL).  I tend to agree with using 1005.

Posted from: 67.163.210.178
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like
Gecko) Chrome/18.0.1025.152 Safari/535.19

-- 
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: Should send() be able to take an ArrayBufferView?

On Wed, Apr 11, 2012 at 12:04 PM, Boris Zbarsky  wrote:

> Seems like right now passing a typed array to send() requires a bit of
> extra hoop-jumping to pass the .buffer instead, right?  Is that desirable?
>

It's a bit worse than that, actually: if you want to send only part of a
buffer, you have to create a whole new ArrayBuffer and copy the data over.
 If you just pass "view.buffer", you'll send the *whole* underlying buffer,
not just the slice represented by the view.  Views are supposed to help
prevent those sorts of copies.  All APIs taking typed arrays should accept
ArrayBufferView.

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.

(This really shouldn't have been a concern; ArrayBuffer and views should
have had a common base class, so they could have been accepted by APIs
interchangeably...)

-- 
Glenn Maynard

Re: Reminder: May face-to-face meetings for HTML and WebApps

2012-04-11 Thread Philippe Le Hegaret

On Wed, 2012-04-11 at 11:03 +1000, Silvia Pfeiffer wrote:
> Is there any possibility to attend remotely for specific topics?

Given the number of individuals in the room, the HTML Chairs at least
decided for not to have a polycom in the room. It didn't seem that the
room would be properly equipped anyway unfortunately,

Philippe

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


On 4/11/12 2:53 PM, Charles Pritchard wrote:

Yes; .buffer has stable semantics across many apis.


Like what?


It does feel awkward when first using it, but the design makes sense after some 
experience.


My point is that we can have overloads taking both ArrayBuffer and 
ArrayBufferView.  Is there any reason _not_ to do that?


-Boris

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

Yes; .buffer has stable semantics across many apis.

It does feel awkward when first using it, but the design makes sense after some 
experience.

On Apr 11, 2012, at 10:04 AM, Boris Zbarsky  wrote:

> Seems like right now passing a typed array to send() requires a bit of extra 
> hoop-jumping to pass the .buffer instead, right?  Is that desirable?
> 
> -Boris
>

Re: Web Intents on WebApps' May 1-2 f2f meeting agenda?

2012-04-11 Thread James Hawkins

Great, thanks!

On Tue, Apr 10, 2012 at 5:30 PM, Arthur Barstow wrote:

> On Apr 10, 2012, at 2:28 PM, ext James Hawkins wrote:
>
> If we can schedule this for May 1, that would be fantastic.  Unfortunately
> something last-minute has come up and I won't be able to attend May 2.
>
>
> I put Web Intents in the 1:30 to 2:30 slot on Tuesday May 1 <
> http://www.w3.org/2008/webapps/wiki/May2012F2FMeeting#Agenda_May_1>.
>
> If that doesn't work, let me know.
>
> -Thanks, Art
>
>
> Thanks,
> James
>
> On Tue, Apr 10, 2012 at 5:00 AM, Arthur Barstow wrote:
>
>> Hi James, Greg, All - in case you did not know, WebApps is having a f2f
>> meeting May 1-2 in Mountain View (logistical details below).
>>
>> Given Web Intents is a joint deliverable with WebApps, perhaps it would
>> be useful to allocate some agenda time for Web Intents e.g. an update on
>> the status, plans, etc.
>>
>> If we do want to allocate some time, we can of course use the W3C voice
>> conference bridge to facilitate remote participants but we would need to
>> nail down the day + time slot.
>>
>> WDYT?
>>
>> -AB=
>>
>
>

Re: Shared workers - use .source instead of .ports[0] ?

On Wed, Apr 11, 2012 at 10:41 AM, Ian Hickson  wrote:
>
> I'm fine with making changes here. The following proposals seem to make
> the most sense, though I'm sure others could work too:
>
>  1. Leave it as is.
>
>  2. Make the .source attribute be of type (MessagePort or WindowProxy)?
>    and add the port to .source, also leaving it in .ports[0].
>
>  3. Make the .source attribute be of type (MessagePort or WindowProxy)?
>    and add the port to .source, making .ports null.
>
>  4. Set the .data attribute to the port, leaving it also in .ports[0].
>
>  5. Set the .data attribute to the port, making .ports null.
>
>  6. Use a new event object instead of MessageEvent.
>
> For back-compat, 1, 2, or 4 seem best.
>
> For similarity with posting things to other windows, 2 or 3 seem best.
> However, I think the similarity is a bit shallow in practice.
>
> For similarity with how messages are handled elsewhere in Workers and when
> using MessagePorts in general, 1 and 4 seem best.
>
> For cleanliness of code, any of 2-6 seem best.
>
> For consistency acros codebases on the Web, 1, 3, 5, or 6 seem best.
>
> If you count each of these considerations as being of equal importance,
> then options 1, 2, 3, and 4 all come out equally good.
>
> Right now the only actual implementation argues for 1, I believe.
>
> I think if I were designing the API from the ground up today I would do
> either 3 or 6. I think with back-compat concerns I would probably
> compromise by going for 2.
>
> Best way to convince me is to ship what you want. :-)

Shared workers is on our radar, but I don't have an ETA for when we'll
ship it. I suspect we'll go with 2 or 3 once we do ship.

/ Jonas

Re: Shared workers - use .source instead of .ports[0] ?

2012-04-11 Thread Ian Hickson


I'm fine with making changes here. The following proposals seem to make 
the most sense, though I'm sure others could work too:

 1. Leave it as is.

 2. Make the .source attribute be of type (MessagePort or WindowProxy)? 
and add the port to .source, also leaving it in .ports[0].

 3. Make the .source attribute be of type (MessagePort or WindowProxy)? 
and add the port to .source, making .ports null.

 4. Set the .data attribute to the port, leaving it also in .ports[0].

 5. Set the .data attribute to the port, making .ports null.

 6. Use a new event object instead of MessageEvent.

For back-compat, 1, 2, or 4 seem best.

For similarity with posting things to other windows, 2 or 3 seem best. 
However, I think the similarity is a bit shallow in practice.

For similarity with how messages are handled elsewhere in Workers and when 
using MessagePorts in general, 1 and 4 seem best.

For cleanliness of code, any of 2-6 seem best.

For consistency acros codebases on the Web, 1, 3, 5, or 6 seem best.

If you count each of these considerations as being of equal importance, 
then options 1, 2, 3, and 4 all come out equally good.

Right now the only actual implementation argues for 1, I believe.

I think if I were designing the API from the ground up today I would do 
either 3 or 6. I think with back-compat concerns I would probably 
compromise by going for 2.

Best way to convince me is to ship what you want. :-)

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

Re: informal survey - on spec philosophy

2012-04-11 Thread Ian Hickson

On Tue, 10 Apr 2012, Paul Libbrecht wrote:
> 
> Anywhere you look, Date.parse is "left to browser interpretation" with 
> the only available standard, ISO-8601, not even being fully implemented 
> in the modern browsers. The very informal w3c note is implemented, while 
> this standard is too big.
> 
> Does HTML5 change this? I'd be glad to hear this.

Date is defined in the JavaScript spec, so HTML doesn't affect this 
particular point.

The contemporary HTML standard tries to define everything that isn't a 
rendering QoI or UI detail, though, to avoid this exact problem. (The 
point Karl posted is a rendering QoI detail, and is therefore 
intentionally left undefined. The alternative is that some implementations 
would just not be compliant, either because they did a worse job than what 
the spec required due to hardware limitations, or they did a better job 
than the spec required. It is pointless to make something non-conforming 
if the implementor can't help but be non-conforming, and it's pointless to 
make something non-conforming that is _better_ than the spec. Hence why 
rendering QoI details are left undefined.)

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

Re: Shared workers - use .source instead of .ports[0] ?

2012-04-11 Thread Andrew Wilson

I guess I'm not a big fan of removing ports[] from the connect event unless
we also remove it from MessageEvent entirely. All the same arguments you've
posed here also apply to MessageEvents in general, so I'd be opposed to
removing it in only one place.

I'm somewhat OK with keeping ports[] but also exposing the port through the
|source| attribute, although "it's OK to put different objects in |source|
as long as they all expose an API called postMessage()" feels inelegant to
me - at least it's backwards compatible.

If we're going to make a non-backwards-compatible change (and I'm not
convinced that we should), I think my preferred solution would be along the
lines of the change described by Jonas earlier - leave |source| alone, get
rid of the |ports| attribute from MessageEvent entirely, and expose the
port in the connect event via the |data| attribute. This is more closely
aligned with the new Transferrable support in postMessage() anyway.

-atw

On Wed, Apr 11, 2012 at 2:05 AM, Simon Pieters  wrote:

> On Wed, 11 Apr 2012 09:29:53 +0200, Jonas Sicking 
> wrote:
>
>  I would prefer to expose the port through .source even if we can't get
>> rid of .ports[0] right now.
>>
>
> I think the longer we wait with removing it, the more legacy will be
> created that relies on its existence.
>
>
>  The ports property is basically useless
>> right now except for this one instance and so while I agree that there
>> might be some confusion in the short term, it doesn't seem like it
>> would be a compatibility problem, and long term it seems like a win
>> that authors wouldn't have to worry about the property at all. It
>> might continue to work if we decide that it's needed for back compat,
>> but it seems like we eventually would be able to get rid of it given
>> how new the property still is.
>>
>> / Jonas
>>
>
>
> --
> Simon Pieters
> Opera Software
>

Should send() be able to take an ArrayBufferView?

Seems like right now passing a typed array to send() requires a bit of 
extra hoop-jumping to pass the .buffer instead, right?  Is that desirable?


-Boris

Re: [XHR] XMLHttpRequest.send("")


On 4/11/12 3:01 AM, Anne van Kesteren wrote:

How about

send(optional (ArrayBuffer or Blob or Document or DOMString or
FormData)? data = null)


I think that should be fine too, yes.  I don't have a strong preference 
for that over the overload version or vice versa.


-Boris

Re: [XHR2] undefined as user/password arguments


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

On 4/11/12 6:57 AM, Jonas Sicking wrote:

open(DOMString method, DOMString url, optional boolean async, optional
DOMString? user, optional DOMString? password);

This means that if anything other than null is passed as value for the
user/password arguments, then the value should be stringified per
normal WebIDL/ECMAScript rules. This includes if the value undefined
is passed


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.


-Boris

Re: [XHR2] undefined as user/password arguments


On 4/11/12 6:57 AM, Jonas Sicking wrote:

open(DOMString method, DOMString url, optional boolean async, optional
DOMString? user, optional DOMString? password);

This means that if anything other than null is passed as value for the
user/password arguments, then the value should be stringified per
normal WebIDL/ECMAScript rules. This includes if the value undefined
is passed


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.


-Boris

[XHR2] undefined as user/password arguments

Hi All,

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

Currently the IDL for the .open function looks as follows:

open(DOMString method, DOMString url, optional boolean async, optional
DOMString? user, optional DOMString? password);

This means that if anything other than null is passed as value for the
user/password arguments, then the value should be stringified per
normal WebIDL/ECMAScript rules. This includes if the value undefined
is passed, which would be converted to "undefined" as both username
and password.

We accidentally made this change a while back, but discovered that
this isn't compatible with the web [1][2]. In particular, the Dojo
toolkit contains code like:

xhr.open(method, ioArgs.url, args.sync !== true, args.user ||
undefined, args.password || undefined);

For "normal" requests this results in the username and password
"undefined" being used. This isn't a big deal since I think many
servers simply ignore the username/password if they are not required
for the resource. But it still seem non-ideal. A bigger deal however
is that for a cross-site request, the requirements in CORS causes such
a request to be denied causing [1].

It also caused sites that use mootools to break when the site was
using basic authentication [2].

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=605296
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=609865

So I suspect we need to add [TreatUndefinedAs=EmptyString] or
[TreatUndefinedAs=Null] (the effect is the same here) to both the user
and password arguments.

/ Jonas

Re: Shared workers - use .source instead of .ports[0] ?

2012-04-11 Thread Simon Pieters


On Wed, 11 Apr 2012 09:29:53 +0200, Jonas Sicking  wrote:


I would prefer to expose the port through .source even if we can't get
rid of .ports[0] right now.


I think the longer we wait with removing it, the more legacy will be  
created that relies on its existence.



The ports property is basically useless
right now except for this one instance and so while I agree that there
might be some confusion in the short term, it doesn't seem like it
would be a compatibility problem, and long term it seems like a win
that authors wouldn't have to worry about the property at all. It
might continue to work if we decide that it's needed for back compat,
but it seems like we eventually would be able to get rid of it given
how new the property still is.

/ Jonas



--
Simon Pieters
Opera Software

Re: Shared workers - use .source instead of .ports[0] ?