Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
Now that the responses on this thread have slowed, I would appreciate if
the participants would please summarize where they think we are on this
issue, e.g. the points of agreement and disagreement, how to move
forward, etc.
Also, coming back to the question in the subject (and I apologize if my
premature subject change caused any confusion or problems), since we
have an open CfC (ends June 9 [1]) to publish a Candidate Recommendation
of Web Messaging, is the Messaging spec going to need to change to
address the issues raised in this thread?
-Art Barstow
[1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0797.html
On Jun/3/2011 8:47 PM, ext Kenneth Russell wrote:
On Fri, Jun 3, 2011 at 4:15 PM, Andrew Wilson wrote:
On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard wrote:
On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson wrote:
significant motivation. The stated motivations for breaking this API
don't
seem compelling to me given the existence of backwards-compatible
alternatives.
This proposal is backwards-compatible. If the argument is an array,
nothing changes, so postMessage(..., [ports]) is equivalent to
postMessage(..., {ports: [ports]}). (The array-only approach can be
done compatibly, too; the object version is just an alternative to
that.) What's backwards-incompatible?
Ah, I missed that piece (to be honest, I haven't been following this
discussion in every detail - I only chimed in because of Jonas' request for
implementation feedback).
For anyone not looking closely at the IDL while reading this, this
means deprecating (for whatever value "deprecate" has on the web) the
ports array in MessageEvent--not the ports parameter to postMessage
(that's a sequence).
Does this affect the API for the SharedWorker onconnect message as well?
Good point; that might inform not deprecating the ports array in
MessageEvent, but leaving it as is.
-Ken
Re: [Bug 12111] New: spec for Storage object getItem(key) method does not match implementation behavior
There are now 11 comments on Web Storage Bug 12111, the last remaining bug before moving this spec back to Last Call: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 If anyone has additional comments, please add them to the bug before the end of this week. I would like to get consensus on this bug soon and would prefer we do so via e-mail and not have to start some type of poll/survey. -Thanks, AB On Feb/17/2011 10:17 AM, ext bugzi...@jessica.w3.org wrote: http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111 Summary: spec for Storage object getItem(key) method does not match implementation behavior Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: m...@w3.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that "The getItem(key) method must return a structured clone of the current value associated with the given key." but all browsers I've tested return a string representation of the value instead.
Re: [FileAPI] Updates to FileAPI Editor's Draft
On May 12, 2011, at 00:49 , Arun Ranganathan wrote: > 2. The read methods on FileReader raise a new exception -- > OperationNotAllowedException -- if multiple concurrent reads are invoked. I > talked this over with Jonas; we think that rather than reuse DOMException > error codes (like INVALID_STATE_ERR), these kinds of scenarios should throw a > distinct exception. Some things on the web (as in life) are simply not > allowed. It may be useful to reuse this exception in other places. I don't have a strong opinion on the ISSUE-182 side of this, but if we're going to create a new exception type that is expected to be reused by other specs can we at least learn from the past and not use numerical codes to identify different variants of the same exception (I'm presuming that other specs reusing this could want to be more precise about why the operation is not allowed, e.g. "user said no", or "Gandalf doesn't want you to pass")? Reuse of DOMException was a long and at times painful coordination effort to make sure that people didn't use the same codes in their own extensions. -- Robin Berjon - http://berjon.com/ - @robinberjon
[Bug 12912] New: Close status code is an unsigned short
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12912 Summary: Close status code is an unsigned short Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: adria...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The code argument to the close() method [1] should be an unsigned short to match the protocol spec [2]. This should also be reflected in the CloseEvent [3]. The protocol document says: If there is a body, the first two bytes of the body MUST be a 2-byte integer (in network byte order) representing a status code defined in Section 7.4. [1] http://dev.w3.org/html5/websockets/#the-websocket-interface [2] http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07#section-4.5.1 [3] http://dev.w3.org/html5/websockets/#closeevent -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 12913] New: Close() should throw the same exception as send() for unpaired surrogates
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12913 Summary: Close() should throw the same exception as send() for unpaired surrogates Product: WebAppsWG Version: unspecified Platform: All URL: http://dev.w3.org/html5/websockets/#dom-websocket-clos e OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: adria...@microsoft.com QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org In the send() method, the spec [1] says: "If the data argument has any unpaired surrogates, then raise an SYNTAX_ERR exception." This should also apply to the close() method for the reason string [2]. [1] http://dev.w3.org/html5/websockets/#dom-websocket-send [2] http://dev.w3.org/html5/websockets/#dom-websocket-close -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 12914] New: close() should throw SYNTAX_ERR if the encoded reason string is too long (protocol supports up to 123 UTF-8 bytes)
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12914 Summary: close() should throw SYNTAX_ERR if the encoded reason string is too long (protocol supports up to 123 UTF-8 bytes) Product: WebAppsWG Version: unspecified Platform: All URL: http://dev.w3.org/html5/websockets/#dom-websocket-clos e OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: adria...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The WebSocket protocol only supports reason strings which once encoded as UTF-8 are up to 123 bytes long. The API should specify what to do if the string is too long once encoded. Our preference is to throw a SYNTAX_ERR. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
RE: [websockets] Reintroducing onerror
On Tuesday, June 07, 2011 10:36 AM, Ian Hickson wrote: > On Tue, 7 Jun 2011, Adrian Bateman wrote: > > This check-in [1] reintroduces the onerror handler that was removed > > previously [2]. Since, in general, WebSocket protocol errors are fatal > > and result in onclose, what is the purpose of adding this back? > > Ian asked me to put it back so that authors can distinguish between a > server closure and a client-initiated error-driven closure. What is the difference between these two cases? When would onerror fire that wouldn't result in onclose with wasClean=false? Isn't the wasClean flag sufficient? Thanks, Adrian.
[Bug 12916] New: Default values for code and reason when wasClean is false
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12916 Summary: Default values for code and reason when wasClean is false Product: WebAppsWG Version: unspecified Platform: All URL: http://dev.w3.org/html5/websockets/#event-definitions OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: adria...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The spec should explicitly indicate the default values for the code and reason attributes if there are no values from the server (a non-clean close). We recommend 0 for the code and null for reason. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 12917] New: "deflate-stream" should be an optional extension when establishing a connection
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12917 Summary: "deflate-stream" should be an optional extension when establishing a connection Product: WebAppsWG Version: unspecified Platform: All URL: http://dev.w3.org/html5/websockets/#websocket OS/Version: All Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: adria...@microsoft.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The spec says: "Establish a WebSocket connection given the set (host, port, resource name, secure), along with the protocols list, a list containing just "deflate-stream" for the extensions, and origin." However, the "deflate-stream" extension is on option and not mandatory. The spec should not require "deflate-stream". -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [FileAPI] Updates to FileAPI Editor's Draft
On Wed, Jun 8, 2011 at 8:16 AM, Robin Berjon wrote: > On May 12, 2011, at 00:49 , Arun Ranganathan wrote: >> 2. The read methods on FileReader raise a new exception -- >> OperationNotAllowedException -- if multiple concurrent reads are invoked. I >> talked this over with Jonas; we think that rather than reuse DOMException >> error codes (like INVALID_STATE_ERR), these kinds of scenarios should throw >> a distinct exception. Some things on the web (as in life) are simply not >> allowed. It may be useful to reuse this exception in other places. > > I don't have a strong opinion on the ISSUE-182 side of this, but if we're > going to create a new exception type that is expected to be reused by other > specs can we at least learn from the past and not use numerical codes to > identify different variants of the same exception (I'm presuming that other > specs reusing this could want to be more precise about why the operation is > not allowed, e.g. "user said no", or "Gandalf doesn't want you to pass")? > Reuse of DOMException was a long and at times painful coordination effort to > make sure that people didn't use the same codes in their own extensions. Yes. These should definitely not have a .code property unless needed for backwards compatibility (which shouldn't be the case for exceptions thrown by FileAPI, unless we want to share them with DOM-Core methods). / Jonas
RE: [websockets] Reintroducing onerror
On Wed, 8 Jun 2011, Adrian Bateman wrote: > On Tuesday, June 07, 2011 10:36 AM, Ian Hickson wrote: > > On Tue, 7 Jun 2011, Adrian Bateman wrote: > > > This check-in [1] reintroduces the onerror handler that was removed > > > previously [2]. Since, in general, WebSocket protocol errors are fatal > > > and result in onclose, what is the purpose of adding this back? > > > > Ian asked me to put it back so that authors can distinguish between a > > server closure and a client-initiated error-driven closure. > > What is the difference between these two cases? When would onerror fire > that wouldn't result in onclose with wasClean=false? Isn't the wasClean > flag sufficient? If the server screwed up the handshake, for instance, you'd get onerror. If the server just closed the connection, you wouldn't, but wasClean would be false. This should hopefully be clear once Ian publishes the latest draft (which he may already have done, I didn't check). HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
My understanding is that we have reached a proposal which respecifies
the "ports" argument to postMessage as an array of objects to
transfer, in such a way that we:
- Maintain 100% backward compatibility
- Enhance the ability to pass MessagePorts, so that the object graph
can refer to them as well
- Allow more object types to participate in transfer of ownership in the future
To the best of my knowledge there are no active points of
disagreement. I think we are only waiting for general consensus from
all interested parties that this is the desired step to take.
If it is, I would be happy to draft proposed edits to the associated
specs; there are several, and the edits may be somewhat involved. I'd
also be happy to share the work with Ian or anyone else.
I don't know the various processes for web specs, but the Web
Messaging spec will definitely need to be updated if we decide to move
in this direction.
-Ken
On Wed, Jun 8, 2011 at 4:30 AM, Arthur Barstow wrote:
> Now that the responses on this thread have slowed, I would appreciate if the
> participants would please summarize where they think we are on this issue,
> e.g. the points of agreement and disagreement, how to move forward, etc.
>
> Also, coming back to the question in the subject (and I apologize if my
> premature subject change caused any confusion or problems), since we have an
> open CfC (ends June 9 [1]) to publish a Candidate Recommendation of Web
> Messaging, is the Messaging spec going to need to change to address the
> issues raised in this thread?
>
> -Art Barstow
>
> [1] http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0797.html
>
> On Jun/3/2011 8:47 PM, ext Kenneth Russell wrote:
>>
>> On Fri, Jun 3, 2011 at 4:15 PM, Andrew Wilson wrote:
>>>
>>> On Fri, Jun 3, 2011 at 3:23 PM, Glenn Maynard wrote:
On Fri, Jun 3, 2011 at 5:15 PM, Andrew Wilson
wrote:
>
> significant motivation. The stated motivations for breaking this API
> don't
> seem compelling to me given the existence of backwards-compatible
> alternatives.
This proposal is backwards-compatible. If the argument is an array,
nothing changes, so postMessage(..., [ports]) is equivalent to
postMessage(..., {ports: [ports]}). (The array-only approach can be
done compatibly, too; the object version is just an alternative to
that.) What's backwards-incompatible?
>>>
>>> Ah, I missed that piece (to be honest, I haven't been following this
>>> discussion in every detail - I only chimed in because of Jonas' request
>>> for
>>> implementation feedback).
>>>
For anyone not looking closely at the IDL while reading this, this
means deprecating (for whatever value "deprecate" has on the web) the
ports array in MessageEvent--not the ports parameter to postMessage
(that's a sequence).
>>>
>>> Does this affect the API for the SharedWorker onconnect message as well?
>>
>> Good point; that might inform not deprecating the ports array in
>> MessageEvent, but leaving it as is.
>>
>> -Ken
>>
>
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell wrote:
> My understanding is that we have reached a proposal which respecifies
> the "ports" argument to postMessage as an array of objects to
> transfer, in such a way that we:
>
Array or object? (by object I mean: {transfer: [arrayBuffer1], ports:
[port]})
>
> - Maintain 100% backward compatibility
> - Enhance the ability to pass MessagePorts, so that the object graph
> can refer to them as well
> - Allow more object types to participate in transfer of ownership in the
> future
>
> To the best of my knowledge there are no active points of
> disagreement. I think we are only waiting for general consensus from
> all interested parties that this is the desired step to take.
>
> If it is, I would be happy to draft proposed edits to the associated
> specs; there are several, and the edits may be somewhat involved. I'd
> also be happy to share the work with Ian or anyone else.
>
> I don't know the various processes for web specs, but the Web
> Messaging spec will definitely need to be updated if we decide to move
> in this direction.
>
> -Ken
>
> On Wed, Jun 8, 2011 at 4:30 AM, Arthur Barstow
> wrote:
> > Now that the responses on this thread have slowed, I would appreciate if
> the
> > participants would please summarize where they think we are on this
> issue,
> > e.g. the points of agreement and disagreement, how to move forward, etc.
> >
> > Also, coming back to the question in the subject (and I apologize if my
> > premature subject change caused any confusion or problems), since we have
> an
> > open CfC (ends June 9 [1]) to publish a Candidate Recommendation of Web
> > Messaging, is the Messaging spec going to need to change to address the
> > issues raised in this thread?
> >
> > -Art Barstow
> >
> > [1]
> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0797.html
> >
>
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
I prefer continuing to use an array for several reasons: simpler
syntax, better type checking at the Web IDL level, and fewer
ECMAScript-specific semantics.
-Ken
On Wed, Jun 8, 2011 at 2:29 PM, David Levin wrote:
>
>
> On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell wrote:
>>
>> My understanding is that we have reached a proposal which respecifies
>> the "ports" argument to postMessage as an array of objects to
>> transfer, in such a way that we:
>
> Array or object? (by object I mean: {transfer: [arrayBuffer1], ports:
> [port]})
>
>>
>> - Maintain 100% backward compatibility
>> - Enhance the ability to pass MessagePorts, so that the object graph
>> can refer to them as well
>> - Allow more object types to participate in transfer of ownership in the
>> future
>>
>> To the best of my knowledge there are no active points of
>> disagreement. I think we are only waiting for general consensus from
>> all interested parties that this is the desired step to take.
>>
>> If it is, I would be happy to draft proposed edits to the associated
>> specs; there are several, and the edits may be somewhat involved. I'd
>> also be happy to share the work with Ian or anyone else.
>>
>> I don't know the various processes for web specs, but the Web
>> Messaging spec will definitely need to be updated if we decide to move
>> in this direction.
>>
>> -Ken
>>
>> On Wed, Jun 8, 2011 at 4:30 AM, Arthur Barstow
>> wrote:
>> > Now that the responses on this thread have slowed, I would appreciate if
>> > the
>> > participants would please summarize where they think we are on this
>> > issue,
>> > e.g. the points of agreement and disagreement, how to move forward, etc.
>> >
>> > Also, coming back to the question in the subject (and I apologize if my
>> > premature subject change caused any confusion or problems), since we
>> > have an
>> > open CfC (ends June 9 [1]) to publish a Candidate Recommendation of Web
>> > Messaging, is the Messaging spec going to need to change to address the
>> > issues raised in this thread?
>> >
>> > -Art Barstow
>> >
>> > [1]
>> > http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0797.html
>> >
>
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
I agree with Kenneth.
-Ben Turner
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell wrote:
> I prefer continuing to use an array for several reasons: simpler
> syntax, better type checking at the Web IDL level, and fewer
> ECMAScript-specific semantics.
>
> -Ken
>
> On Wed, Jun 8, 2011 at 2:29 PM, David Levin wrote:
>>
>>
>> On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell wrote:
>>>
>>> My understanding is that we have reached a proposal which respecifies
>>> the "ports" argument to postMessage as an array of objects to
>>> transfer, in such a way that we:
>>
>> Array or object? (by object I mean: {transfer: [arrayBuffer1], ports:
>> [port]})
>>
>>>
>>> - Maintain 100% backward compatibility
>>> - Enhance the ability to pass MessagePorts, so that the object graph
>>> can refer to them as well
>>> - Allow more object types to participate in transfer of ownership in the
>>> future
>>>
>>> To the best of my knowledge there are no active points of
>>> disagreement. I think we are only waiting for general consensus from
>>> all interested parties that this is the desired step to take.
>>>
>>> If it is, I would be happy to draft proposed edits to the associated
>>> specs; there are several, and the edits may be somewhat involved. I'd
>>> also be happy to share the work with Ian or anyone else.
>>>
>>> I don't know the various processes for web specs, but the Web
>>> Messaging spec will definitely need to be updated if we decide to move
>>> in this direction.
>>>
>>> -Ken
>>>
>>> On Wed, Jun 8, 2011 at 4:30 AM, Arthur Barstow
>>> wrote:
>>> > Now that the responses on this thread have slowed, I would appreciate if
>>> > the
>>> > participants would please summarize where they think we are on this
>>> > issue,
>>> > e.g. the points of agreement and disagreement, how to move forward, etc.
>>> >
>>> > Also, coming back to the question in the subject (and I apologize if my
>>> > premature subject change caused any confusion or problems), since we
>>> > have an
>>> > open CfC (ends June 9 [1]) to publish a Candidate Recommendation of Web
>>> > Messaging, is the Messaging spec going to need to change to address the
>>> > issues raised in this thread?
>>> >
>>> > -Art Barstow
>>> >
>>> > [1]
>>> > http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0797.html
>>> >
>>
>
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell wrote:
> I prefer continuing to use an array for several reasons: simpler
> syntax, better type checking at the Web IDL level, and fewer
> ECMAScript-specific semantics.
>
An array makes it harder to do future modifications.
Also with the array, how does "Enhance the ability to pass MessagePorts, so
that the object graph can refer to them as well" work? Specifically,
consider an array that contains [arrayBuffer1, port1]. Is port1 something in
the object graph or a port to be transfer as before?
dave
>
> -Ken
>
> On Wed, Jun 8, 2011 at 2:29 PM, David Levin wrote:
> >
> >
> > On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell wrote:
> >>
> >> My understanding is that we have reached a proposal which respecifies
> >> the "ports" argument to postMessage as an array of objects to
> >> transfer, in such a way that we:
> >
> > Array or object? (by object I mean: {transfer: [arrayBuffer1], ports:
> > [port]})
> >
> >>
> >> - Maintain 100% backward compatibility
> >> - Enhance the ability to pass MessagePorts, so that the object graph
> >> can refer to them as well
> >> - Allow more object types to participate in transfer of ownership in
> the
> >> future
> >>
> >> To the best of my knowledge there are no active points of
> >> disagreement. I think we are only waiting for general consensus from
> >> all interested parties that this is the desired step to take.
> >>
> >> If it is, I would be happy to draft proposed edits to the associated
> >> specs; there are several, and the edits may be somewhat involved. I'd
> >> also be happy to share the work with Ian or anyone else.
> >>
> >> I don't know the various processes for web specs, but the Web
> >> Messaging spec will definitely need to be updated if we decide to move
> >> in this direction.
> >>
> >> -Ken
> >>
> >> On Wed, Jun 8, 2011 at 4:30 AM, Arthur Barstow
> >> wrote:
> >> > Now that the responses on this thread have slowed, I would appreciate
> if
> >> > the
> >> > participants would please summarize where they think we are on this
> >> > issue,
> >> > e.g. the points of agreement and disagreement, how to move forward,
> etc.
> >> >
> >> > Also, coming back to the question in the subject (and I apologize if
> my
> >> > premature subject change caused any confusion or problems), since we
> >> > have an
> >> > open CfC (ends June 9 [1]) to publish a Candidate Recommendation of
> Web
> >> > Messaging, is the Messaging spec going to need to change to address
> the
> >> > issues raised in this thread?
> >> >
> >> > -Art Barstow
> >> >
> >> > [1]
> >> >
> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0797.html
> >> >
> >
>
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 8, 2011 at 2:39 PM, David Levin wrote:
>
>
> On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell wrote:
>>
>> I prefer continuing to use an array for several reasons: simpler
>> syntax, better type checking at the Web IDL level, and fewer
>> ECMAScript-specific semantics.
>
> An array makes it harder to do future modifications.
Possibly, but it makes the design of this modification cleaner.
> Also with the array, how does "Enhance the ability to pass MessagePorts, so
> that the object graph can refer to them as well" work? Specifically,
> consider an array that contains [arrayBuffer1, port1]. Is port1 something in
> the object graph or a port to be transfer as before?
In order to maintain backward compatibility, the clone of port1 would
show up in the "ports" attribute of the MessageEvent on the other
side. Additionally, during the structured clone of the object graph,
any references to port1 would be updated to point to the clone of
port1. (The latter is new behavior, and brings MessagePorts in line
with the desired transfer-of-ownership semantics.)
All other objects in the array (which, as Ian originally proposed,
would implement some interface like "Transferable" for better Web IDL
type checking) would simply indicate objects in the graph to be
transferred rather than copied.
Note: it would still be possible to evolve the API to transfer all
objects of a certain type. We would just need to change the type of
the "ports" or "transfer" array from Transferable[] to any[] and spec
what happens when a constructor function is placed in the array.
-Ken
> dave
>
>>
>> -Ken
>>
>> On Wed, Jun 8, 2011 at 2:29 PM, David Levin wrote:
>> >
>> >
>> > On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell wrote:
>> >>
>> >> My understanding is that we have reached a proposal which respecifies
>> >> the "ports" argument to postMessage as an array of objects to
>> >> transfer, in such a way that we:
>> >
>> > Array or object? (by object I mean: {transfer: [arrayBuffer1], ports:
>> > [port]})
>> >
>> >>
>> >> - Maintain 100% backward compatibility
>> >> - Enhance the ability to pass MessagePorts, so that the object graph
>> >> can refer to them as well
>> >> - Allow more object types to participate in transfer of ownership in
>> >> the
>> >> future
>> >>
>> >> To the best of my knowledge there are no active points of
>> >> disagreement. I think we are only waiting for general consensus from
>> >> all interested parties that this is the desired step to take.
>> >>
>> >> If it is, I would be happy to draft proposed edits to the associated
>> >> specs; there are several, and the edits may be somewhat involved. I'd
>> >> also be happy to share the work with Ian or anyone else.
>> >>
>> >> I don't know the various processes for web specs, but the Web
>> >> Messaging spec will definitely need to be updated if we decide to move
>> >> in this direction.
>> >>
>> >> -Ken
>> >>
>> >> On Wed, Jun 8, 2011 at 4:30 AM, Arthur Barstow
>> >> wrote:
>> >> > Now that the responses on this thread have slowed, I would appreciate
>> >> > if
>> >> > the
>> >> > participants would please summarize where they think we are on this
>> >> > issue,
>> >> > e.g. the points of agreement and disagreement, how to move forward,
>> >> > etc.
>> >> >
>> >> > Also, coming back to the question in the subject (and I apologize if
>> >> > my
>> >> > premature subject change caused any confusion or problems), since we
>> >> > have an
>> >> > open CfC (ends June 9 [1]) to publish a Candidate Recommendation of
>> >> > Web
>> >> > Messaging, is the Messaging spec going to need to change to address
>> >> > the
>> >> > issues raised in this thread?
>> >> >
>> >> > -Art Barstow
>> >> >
>> >> > [1]
>> >> >
>> >> > http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0797.html
>> >> >
>> >
>
>
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
ok.
On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell wrote:
> On Wed, Jun 8, 2011 at 2:39 PM, David Levin wrote:
> >
> >
> > On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell wrote:
> >>
> >> I prefer continuing to use an array for several reasons: simpler
> >> syntax, better type checking at the Web IDL level, and fewer
> >> ECMAScript-specific semantics.
> >
> > An array makes it harder to do future modifications.
>
> Possibly, but it makes the design of this modification cleaner.
>
> > Also with the array, how does "Enhance the ability to pass MessagePorts,
> so
> > that the object graph can refer to them as well" work? Specifically,
> > consider an array that contains [arrayBuffer1, port1]. Is port1 something
> in
> > the object graph or a port to be transfer as before?
>
> In order to maintain backward compatibility, the clone of port1 would
> show up in the "ports" attribute of the MessageEvent on the other
> side. Additionally, during the structured clone of the object graph,
> any references to port1 would be updated to point to the clone of
> port1. (The latter is new behavior, and brings MessagePorts in line
> with the desired transfer-of-ownership semantics.)
>
> All other objects in the array (which, as Ian originally proposed,
> would implement some interface like "Transferable" for better Web IDL
> type checking) would simply indicate objects in the graph to be
> transferred rather than copied.
>
> Note: it would still be possible to evolve the API to transfer all
> objects of a certain type. We would just need to change the type of
> the "ports" or "transfer" array from Transferable[] to any[] and spec
> what happens when a constructor function is placed in the array.
>
> -Ken
>
> > dave
> >
> >>
> >> -Ken
> >>
> >> On Wed, Jun 8, 2011 at 2:29 PM, David Levin wrote:
> >> >
> >> >
> >> > On Wed, Jun 8, 2011 at 2:24 PM, Kenneth Russell
> wrote:
> >> >>
> >> >> My understanding is that we have reached a proposal which respecifies
> >> >> the "ports" argument to postMessage as an array of objects to
> >> >> transfer, in such a way that we:
> >> >
> >> > Array or object? (by object I mean: {transfer: [arrayBuffer1], ports:
> >> > [port]})
> >> >
> >> >>
> >> >> - Maintain 100% backward compatibility
> >> >> - Enhance the ability to pass MessagePorts, so that the object graph
> >> >> can refer to them as well
> >> >> - Allow more object types to participate in transfer of ownership in
> >> >> the
> >> >> future
> >> >>
> >> >> To the best of my knowledge there are no active points of
> >> >> disagreement. I think we are only waiting for general consensus from
> >> >> all interested parties that this is the desired step to take.
> >> >>
> >> >> If it is, I would be happy to draft proposed edits to the associated
> >> >> specs; there are several, and the edits may be somewhat involved. I'd
> >> >> also be happy to share the work with Ian or anyone else.
> >> >>
> >> >> I don't know the various processes for web specs, but the Web
> >> >> Messaging spec will definitely need to be updated if we decide to
> move
> >> >> in this direction.
> >> >>
> >> >> -Ken
> >> >>
> >> >> On Wed, Jun 8, 2011 at 4:30 AM, Arthur Barstow <
> art.bars...@nokia.com>
> >> >> wrote:
> >> >> > Now that the responses on this thread have slowed, I would
> appreciate
> >> >> > if
> >> >> > the
> >> >> > participants would please summarize where they think we are on this
> >> >> > issue,
> >> >> > e.g. the points of agreement and disagreement, how to move forward,
> >> >> > etc.
> >> >> >
> >> >> > Also, coming back to the question in the subject (and I apologize
> if
> >> >> > my
> >> >> > premature subject change caused any confusion or problems), since
> we
> >> >> > have an
> >> >> > open CfC (ends June 9 [1]) to publish a Candidate Recommendation of
> >> >> > Web
> >> >> > Messaging, is the Messaging spec going to need to change to address
> >> >> > the
> >> >> > issues raised in this thread?
> >> >> >
> >> >> > -Art Barstow
> >> >> >
> >> >> > [1]
> >> >> >
> >> >> >
> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0797.html
> >> >> >
> >> >
> >
> >
>
[widgets] WARP tests
Hi, A few typos were found in the WARP tests. I have updated them so hopefully they are now correct. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 8, 2011 at 5:33 PM, Kenneth Russell wrote: > I prefer continuing to use an array for several reasons: simpler > syntax, better type checking at the Web IDL level, and fewer > ECMAScript-specific semantics. > > Possibly, but it makes the design of this modification cleaner. These don't sound too critical to me, and WebIDL supports using objects like this now. I suspect we'll start to see more of the optional-parameters-in-an-object pattern, as APIs grow more complex and start to need it more often. I don't think it's inherently cleaner or simpler either way--parameters in an object is very natural in JS, and much clearer once you reach four or five parameters. But if the simple array approach works, then there's just no need. -- Glenn Maynard
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell wrote: > On Wed, Jun 8, 2011 at 2:39 PM, David Levin wrote: >> >> >> On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell wrote: >>> >>> I prefer continuing to use an array for several reasons: simpler >>> syntax, better type checking at the Web IDL level, and fewer >>> ECMAScript-specific semantics. >> >> An array makes it harder to do future modifications. > > Possibly, but it makes the design of this modification cleaner. > >> Also with the array, how does "Enhance the ability to pass MessagePorts, so >> that the object graph can refer to them as well" work? Specifically, >> consider an array that contains [arrayBuffer1, port1]. Is port1 something in >> the object graph or a port to be transfer as before? > > In order to maintain backward compatibility, the clone of port1 would > show up in the "ports" attribute of the MessageEvent on the other > side. Additionally, during the structured clone of the object graph, > any references to port1 would be updated to point to the clone of > port1. (The latter is new behavior, and brings MessagePorts in line > with the desired transfer-of-ownership semantics.) > > All other objects in the array (which, as Ian originally proposed, > would implement some interface like "Transferable" for better Web IDL > type checking) would simply indicate objects in the graph to be > transferred rather than copied. This all sounds great to me, but I think we should additionally make the 'ports' attribute on the MessageEvent interface deprecated. The only use case for it is to support existing code which doesn't pass ports in the object graph but rather only in the array in the second argument (i.e. the formerly "ports" argument). By deprecating it, I mean either: 1. Mark it, using prose, as deprecated in the specification. 2. Remove it from the specification but allow existing implementations of it to keep it as long as they feel needed to retain compatibility with existing code. / Jonas
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 8, 2011 at 6:14 PM, Jonas Sicking wrote: > On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell wrote: >> On Wed, Jun 8, 2011 at 2:39 PM, David Levin wrote: >>> >>> >>> On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell wrote: I prefer continuing to use an array for several reasons: simpler syntax, better type checking at the Web IDL level, and fewer ECMAScript-specific semantics. >>> >>> An array makes it harder to do future modifications. >> >> Possibly, but it makes the design of this modification cleaner. >> >>> Also with the array, how does "Enhance the ability to pass MessagePorts, so >>> that the object graph can refer to them as well" work? Specifically, >>> consider an array that contains [arrayBuffer1, port1]. Is port1 something in >>> the object graph or a port to be transfer as before? >> >> In order to maintain backward compatibility, the clone of port1 would >> show up in the "ports" attribute of the MessageEvent on the other >> side. Additionally, during the structured clone of the object graph, >> any references to port1 would be updated to point to the clone of >> port1. (The latter is new behavior, and brings MessagePorts in line >> with the desired transfer-of-ownership semantics.) >> >> All other objects in the array (which, as Ian originally proposed, >> would implement some interface like "Transferable" for better Web IDL >> type checking) would simply indicate objects in the graph to be >> transferred rather than copied. > > This all sounds great to me, but I think we should additionally make > the 'ports' attribute on the MessageEvent interface deprecated. > > The only use case for it is to support existing code which doesn't > pass ports in the object graph but rather only in the array in the > second argument (i.e. the formerly "ports" argument). That's not quite correct; as was pointed out earlier in the thread, SharedWorkerGlobalScope's onconnect message relies on receiving the message port with which to communicate to the outside world in the zeroth element of the ports array. See step 7.7.5 in http://www.whatwg.org/specs/web-workers/current-work/#shared-workers-and-the-sharedworker-interface . Thinking about this more, that port could be sent as the data attribute of the event instead of the empty string. Then the ports attribute on MessageEvent could be safely deprecated. -Ken > By deprecating it, I mean either: > > 1. Mark it, using prose, as deprecated in the specification. > 2. Remove it from the specification but allow existing implementations > of it to keep it as long as they feel needed to retain compatibility > with existing code. > > / Jonas >
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 8, 2011 at 9:14 PM, Jonas Sicking wrote: > This all sounds great to me, but I think we should additionally make > the 'ports' attribute on the MessageEvent interface deprecated. > > The only use case for it is to support existing code which doesn't > pass ports in the object graph but rather only in the array in the > second argument (i.e. the formerly "ports" argument). > > By deprecating it, I mean either: > > 1. Mark it, using prose, as deprecated in the specification. > 2. Remove it from the specification but allow existing implementations > of it to keep it as long as they feel needed to retain compatibility > with existing code. MessageEvent is also used by the onconnect event. -- Glenn Maynard
Re: What changes to Web Messaging spec are proposed? [Was: Re: Using ArrayBuffer as payload for binary data to/from Web Workers]
On Wed, Jun 8, 2011 at 6:26 PM, Kenneth Russell wrote: > On Wed, Jun 8, 2011 at 6:14 PM, Jonas Sicking wrote: >> On Wed, Jun 8, 2011 at 4:27 PM, Kenneth Russell wrote: >>> On Wed, Jun 8, 2011 at 2:39 PM, David Levin wrote: On Wed, Jun 8, 2011 at 2:33 PM, Kenneth Russell wrote: > > I prefer continuing to use an array for several reasons: simpler > syntax, better type checking at the Web IDL level, and fewer > ECMAScript-specific semantics. An array makes it harder to do future modifications. >>> >>> Possibly, but it makes the design of this modification cleaner. >>> Also with the array, how does "Enhance the ability to pass MessagePorts, so that the object graph can refer to them as well" work? Specifically, consider an array that contains [arrayBuffer1, port1]. Is port1 something in the object graph or a port to be transfer as before? >>> >>> In order to maintain backward compatibility, the clone of port1 would >>> show up in the "ports" attribute of the MessageEvent on the other >>> side. Additionally, during the structured clone of the object graph, >>> any references to port1 would be updated to point to the clone of >>> port1. (The latter is new behavior, and brings MessagePorts in line >>> with the desired transfer-of-ownership semantics.) >>> >>> All other objects in the array (which, as Ian originally proposed, >>> would implement some interface like "Transferable" for better Web IDL >>> type checking) would simply indicate objects in the graph to be >>> transferred rather than copied. >> >> This all sounds great to me, but I think we should additionally make >> the 'ports' attribute on the MessageEvent interface deprecated. >> >> The only use case for it is to support existing code which doesn't >> pass ports in the object graph but rather only in the array in the >> second argument (i.e. the formerly "ports" argument). > > That's not quite correct; as was pointed out earlier in the thread, > SharedWorkerGlobalScope's onconnect message relies on receiving the > message port with which to communicate to the outside world in the > zeroth element of the ports array. See step 7.7.5 in > http://www.whatwg.org/specs/web-workers/current-work/#shared-workers-and-the-sharedworker-interface > . > > Thinking about this more, that port could be sent as the data > attribute of the event instead of the empty string. Then the ports > attribute on MessageEvent could be safely deprecated. Sounds great to me. / Jonas
