This is just a change to the "Dependencies" section right?

The other usage can be cleaned up as well. E.g. IDL defines algorithms for extracting bytes, defines BufferSource as typedef for ArrayBuffer/ArrayBufferView.

I don't understand what exactly it is you want updated. I don't extract bytes anywhere, do I? Do you see anything where BufferSource would be useful other than removing one line of IDL from the WebSocket IDL?

WebSocket, yes, it also extracts the data.

Structured cloning extracts the data.

But yes, also "Dependencies".

I guess I don't understand what you mean by "extracts the data" then? Can you elaborate on what you'd like changed?

For WebSocket:

"The data to be sent is the data stored in the buffer described by the ArrayBuffer object."

"The data to be sent is the data stored in the section of the buffer described by the ArrayBuffer object that data references."

This should instead reference the copy algorithm from IDL (and use BufferSource). In particular I think the second sentence is currently wrong as a view can represent a segment of an underlying buffer.


For Transferable objects:

"ArrayBuffer [ECMA262]"

That is defined in IDL now. (You also cannot reference JavaScript objects and then use them in a typedef.)

The neuter bit here is out of sync as well, but there's a separate bug for that.


For internal structured cloning algorithm: this could reference the copy algorithm for ArrayBuffer, but it might not be worth it to change that.



For dependencies:

The ArrayBufferView typedef is no longer needed. ArrayBuffer no longer needs to be defined as part of JavaScript.

(In reply to Anne from comment #6)
> For WebSocket:
> 
> "The data to be sent is the data stored in the buffer described by the
> ArrayBuffer object."
> 
> "The data to be sent is the data stored in the section of the buffer
> described by the ArrayBuffer object that data references."
> 
> This should instead reference the copy algorithm from IDL (and use
> BufferSource).

I don't understand why. The algorithms just do type checking, and otherwise basically do exactly what the HTML spec says. Why isn't the type-checking done when the arguments are passed?


> In particular I think the second sentence is currently wrong
> as a view can represent a segment of an underlying buffer.

The second sentence handles that find as far as I can tell.


The other changes are those mentioned in comment 1 (and the things that implicitly result from those changes).

(In reply to Ian 'Hixie' Hickson from comment #7)
> I don't understand why.

If only for the simple fact that then nobody thinks this situation is somehow special.


> The second sentence handles that find as far as I can tell.

I don't really see how. You introduce terms such as "buffer" that have no meaning in either IDL or JavaScript. You say the buffer is described by the ArrayBuffer object, while the ArrayBuffer object can represent a larger buffer than the view represents. It's not at all clear to me.

(In reply to Anne from comment #8)
> If only for the simple fact that then nobody thinks this situation is
> somehow special.

I'm not arguing that HTML should be different, I'm saying nobody should have to do this. Why aren't we just checking this in the argument checking step, instead of requiring that all users of ArrayBuffer have this boilerplate?


> > The second sentence handles that find as far as I can tell.
> 
> I don't really see how. You introduce terms such as "buffer" that have no
> meaning in either IDL or JavaScript. You say the buffer is described by the
> ArrayBuffer object, while the ArrayBuffer object can represent a larger
> buffer than the view represents. It's not at all clear to me.

It references "the section of the buffer" not just "the buffer". This is just English, the word "buffer" is a well-known computer science term that seems to map fine to the WebIDL/JS terminology. I mean, it's basically the same as what the WebIDL spec says — it just does a bunch of type checking which I think should happen at argument checking time, and then just returns "a reference to or copy of (as required) the length bytes in data starting at byte offset offset" which is no more defined than what HTML says, when you get right down to it.

*** Bug 26968 has been marked as a duplicate of this bug. ***

I think IDL does not do it at the point of argument checking because then it would require an upfront decision about whether to get the bytes by-copy or by-reference (when we introduced this we were not quite sure what would be a better default). If we can find a decent way to do that, that might be better model though. I recommend filing a bug on IDL.

Don't all APIs know whether they're copying or referencing the data?

I think they do, yes.

If the APIs know what they're doing, then I think the IDL should just do the checking up-front. That way the behaviour is much more consistent.

As I said, I recommend filing a bug on IDL.

bz, would it make sense to update IDL for this?

Not all consumers know whether they're copying or referencing.  For example, a WebGL implementation might do either one depending on how it's actually implemented.

That said, what exact checking would you expect to be done up front if an API _did_ know whether it's copying or referencing?

Well the behaviour can't depend on how it's implemented, that would be visibly non-interoperable. The question is just whether any specs sometimes do one and sometimes do the other, as opposed to any method always doing one or the other.

In any case it looks like the behaviour now is just always the same. I'm not sure if I misread it before or if it changed. The checking I'm referring to is the checking in the algorithm introduced as "When getting a reference to or getting a copy of the bytes held by a buffer source that is an ECMAScript ArrayBuffer, DataView or typed array object, these steps must be followed:" in the Web IDL spec. I argue that this should just move to argument checking step of method invocation, so that we don't get weirdness about exactly when these checks happen.

Ah, I see.

So just to make sure we're on the same page, this algorithm does the following checks:

Step 5: Check whether O has a [[ViewedArrayBuffer]] internal slot.  If it does, O is a typed array or data view; if it does not, O is a ArrayBuffer.  This check is just needed to decide where exactly the data lives.

Step 5.2: In the "[[ViewedArrayBuffer]] exists" case, check for the value in the slot being undefined.  This is only possible if the typed array is in the middle of being constructed and hasn't been initialized yet.  And that state is going to go away with the edits Allen is making to the ES6 constructor protocol right now.  So at that point, this check will go away, I'd think.

Step 7: Checks for a detached buffer.  This presumes that extracting data from a detached buffer should be a TypeError as opposed to silently getting an empty buffer.  This check cannot be performed during argument conversion, because conversion of a later argument can detach the buffer, as can anything else which allows JS to run.  Therefore, this check MUST be performed immediately before the data is extracted.  Furthermore, specifications and implementations that reference the data instead of copying it must ensure that no script runs between the "getting a reference to" algorithm running and the last use of the data.

Is there some other check I'm missing that's at issue here?

Ah, and right after that comment I got the mail about http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#january_15_2015_draft_rev_31 now existing and all the checks for the value in [[ViewedArrayBuffer]] being undefined are gone in there.

At this point, the algorithm doesn't seem necessary any more. We should just define what bytes these objects represent, and then the calling specs would be much more readable. IMHO.

That is, instead of:

   ...
   5. Let _data_ be the result of _getting a copy of the bytes held by a buffer
      source_ /foo/. If this throws an exception, then ...
   ...

...we'd just say:

   ...
   5. If /foo/ is neutered, then ...
   6. Let _data_ be the data represented by /foo/.
   ...

Similarly, the "detach" algorithm seems pointlessly trivial as specced. What value does it add? We should just make the JS spec referenceable directly.

>   6. Let _data_ be the data represented by /foo/.

Then we need to define "the data represented by /foo/", right?  This is not a theoretical concern; implementors and spec authors have screwed this up in the past.  Which is why it's good to have one place which defines this concept that everyone else can then reference.

Given such a shared definition, your proposal sounds ok to me, except there is no such thing as "neutered" anymore.  It's called "detached".

Referencing JavaScript directly doesn't make sense, unless IDL values can sometimes be JavaScript objects. The layering is:

  JavaScript -> IDL -> feature spec -> IDL -> JavaScript

IDL values can totally be JS objects, right?  I mean, consider the "object" type.  It's "an IDL value that represents the given JS object", but presumably that means that as long as you're willing to make your prose JS-specific you can unambiguously talk about the JS object represented by the "object" type IDL value.

The various BufferSource types have similar behavior.

https://github.com/whatwg/html/commit/52f96c455a53763a7fe00162c067da6adb20e62c fixes the dependencies section, but the changes to use BufferSource and to be clear about copying vs. not are still to-do.

I thought about fixing this, but bug 28798 should really be fixed first. With that bug fixed for our cases we don't even have to worry about extracting bytes, IDL will just hand us bytes.

It seems this needs to be fixed across the specification ecosystem as part of the Web IDL work, and is not worth tracking as HTML specifically. So, I will close this and let us continue tracking work in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28798 and its GitHub successor.