On Fri, Jun 24, 2011 at 4:27 PM, Kenneth Russell wrote:
> On Fri, Jun 24, 2011 at 3:43 PM, Ian Hickson wrote:
>> On Fri, 24 Jun 2011, Kenneth Russell wrote:
>>>
>>> Slightly larger issue. In the typed array spec, views like Float32Array
>>> refer to an ArrayBuffer instance. It's desired to be abl
On Fri, Jun 24, 2011 at 3:43 PM, Ian Hickson wrote:
> On Fri, 24 Jun 2011, Kenneth Russell wrote:
>>
>> Slightly larger issue. In the typed array spec, views like Float32Array
>> refer to an ArrayBuffer instance. It's desired to be able to transfer
>> multiple views of the same ArrayBuffer in the
On Fri, 24 Jun 2011, Kenneth Russell wrote:
>
> Slightly larger issue. In the typed array spec, views like Float32Array
> refer to an ArrayBuffer instance. It's desired to be able to transfer
> multiple views of the same ArrayBuffer in the same postMessage call.
> Currently, because each Transf
On Thu, Jun 23, 2011 at 4:52 PM, Ian Hickson wrote:
> On Tue, 21 Jun 2011, Ian Hickson wrote:
>>
>> How about we just make postMessage() take the object to clone in the first
>> argument, an array of objects to transfer in the second; on the other
>> side, the author receives the object cloned, wi
On Tue, 21 Jun 2011, Ian Hickson wrote:
>
> How about we just make postMessage() take the object to clone in the first
> argument, an array of objects to transfer in the second; on the other
> side, the author receives the object cloned, with anything listed in the
> array and in the structured
On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard wrote:
> On Wed, Jun 22, 2011 at 1:57 AM, David Levin wrote:
>>
>> Let's say the call doesn't throw when given a type B that isn't
>> transferrable.
>> Let's also say some later changes the javascript code and uses B after the
>> postMessage call.
>
On Wed, Jun 22, 2011 at 2:31 AM, Glenn Maynard wrote:
> On Wed, Jun 22, 2011 at 4:33 AM, David Levin wrote:
>
>> Making people use a helper function like that is just making them jump an
>>> unnecessary hoop.
>>>
>>
>> It makes them jump through another hoop to potentially misuse the api.
>>
>
>
On Wed, Jun 22, 2011 at 2:31 AM, Glenn Maynard wrote:
> On Wed, Jun 22, 2011 at 4:33 AM, David Levin wrote:
>
>> Making people use a helper function like that is just making them jump an
>>> unnecessary hoop.
>>>
>>
>> It makes them jump through another hoop to potentially misuse the api.
>>
>
>
On Wed, Jun 22, 2011 at 4:33 AM, David Levin wrote:
> Making people use a helper function like that is just making them jump an
>> unnecessary hoop.
>>
>
> It makes them jump through another hoop to potentially misuse the api.
>
No, it's another hoop that *everyone* has to jump through to use th
On Wed, Jun 22, 2011 at 12:26 AM, Glenn Maynard wrote:
> On Wed, Jun 22, 2011 at 3:14 AM, David Levin wrote:
>
>> On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard wrote:
>>
>>> On Wed, Jun 22, 2011 at 1:57 AM, David Levin wrote:
>>>
Let's say the call doesn't throw when given a type B that
On Wed, Jun 22, 2011 at 3:14 AM, David Levin wrote:
> On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard wrote:
>
>> On Wed, Jun 22, 2011 at 1:57 AM, David Levin wrote:
>>
>>> Let's say the call doesn't throw when given a type B that isn't
>>> transferrable.
>>> Let's also say some later changes t
On Tue, Jun 21, 2011 at 11:43 PM, Glenn Maynard wrote:
> On Wed, Jun 22, 2011 at 1:57 AM, David Levin wrote:
>
>> Let's say the call doesn't throw when given a type B that isn't
>> transferrable.
>> Let's also say some later changes the javascript code and uses B after the
>> postMessage call.
>
On Wed, Jun 22, 2011 at 1:57 AM, David Levin wrote:
> Let's say the call doesn't throw when given a type B that isn't
> transferrable.
> Let's also say some later changes the javascript code and uses B after the
> postMessage call.
> Everything work. No throw is done and B isn't "gutted" because
On Tue, Jun 21, 2011 at 10:48 PM, Glenn Maynard wrote:
> On Wed, Jun 22, 2011 at 1:25 AM, David Levin wrote:
>
>> On Tue, Jun 21, 2011 at 9:27 PM, Glenn Maynard wrote:
>>
>>> What happens if an object is included in the second list that doesn't
>>> support transfer? Ian said that it would thro
On Wed, Jun 22, 2011 at 1:25 AM, David Levin wrote:
> On Tue, Jun 21, 2011 at 9:27 PM, Glenn Maynard wrote:
>
>> What happens if an object is included in the second list that doesn't
>> support transfer? Ian said that it would throw, but I'm not sure that's
>> best.
>>
>
> If it doesn't throw,
On Tue, Jun 21, 2011 at 9:27 PM, Glenn Maynard wrote:
> What happens if an object is included in the second list that doesn't
> support transfer? Ian said that it would throw, but I'm not sure that's
> best.
>
If it doesn't throw, doesn't that introduce the backwards compat issue when
something
What happens if an object is included in the second list that doesn't
support transfer? Ian said that it would throw, but I'm not sure that's
best.
Suppose Firefox N supports transferring ArrayBuffer, and Firefox N+1 adds
support for transferring ImageData. Developers working with Firefox N+1
wr
On Tue, Jun 21, 2011 at 11:07 AM, Ian Hickson wrote:
> On Tue, 21 Jun 2011, Jonas Sicking wrote:
>> On Tue, Jun 21, 2011 at 12:39 AM, Ian Hickson wrote:
>> > On Mon, 20 Jun 2011, Jonas Sicking wrote:
>> >>
>> >> If data appears both in the .ports array and the .data property, then
>> >> people wi
On Tue, 21 Jun 2011, Jonas Sicking wrote:
> On Tue, Jun 21, 2011 at 12:39 AM, Ian Hickson wrote:
> > On Mon, 20 Jun 2011, Jonas Sicking wrote:
> >>
> >> If data appears both in the .ports array and the .data property, then
> >> people will be tempted to create protocols which only work if the
>
On Tue, Jun 21, 2011 at 12:39 AM, Ian Hickson wrote:
> On Mon, 20 Jun 2011, Jonas Sicking wrote:
>>
>> If data appears both in the .ports array and the .data property, then
>> people will be tempted to create protocols which only work if the array
>> buffer is transferred, i.e. if the receiver onl
On Mon, 20 Jun 2011, Jonas Sicking wrote:
>
> If data appears both in the .ports array and the .data property, then
> people will be tempted to create protocols which only work if the array
> buffer is transferred, i.e. if the receiver only looks in .ports. I.e.
> people will likely end up with
On Mon, Jun 20, 2011 at 3:54 PM, Ian Hickson wrote:
>
> So the proposal that seems to address the most concerns raised in this
> thread would be to have postMessage() work like this:
>
> postMessage({ object }, [ array ]);
>
> ...with it resulting in an event that contains both {object} and [arr
So the proposal that seems to address the most concerns raised in this
thread would be to have postMessage() work like this:
postMessage({ object }, [ array ]);
...with it resulting in an event that contains both {object} and [array],
where everything in the array is transferred, and everyt
Kenneth Russell
Subject: FW: What changes to Web Messaging spec are proposed? [Was: Re: Using
ArrayBuffer as payload for binary data to/from Web Workers]
>From: Arthur Barstow [mailto:art.bars...@nokia.com] On Jun/8/2011 5:24
>PM, ext Kenneth Russell wrote:
>> My understanding is that we
>From: Arthur Barstow [mailto:art.bars...@nokia.com]
>On Jun/8/2011 5:24 PM, ext 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:
>>
>> - Maintain 10
On Jun/8/2011 5:24 PM, ext 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:
- Maintain 100% backward compatibility
- Enhance the ability to pass MessageP
On Fri, 10 Jun 2011, Travis Leithead wrote:
>
> This looks like a mis-reading on my part of step 2 of the postMessage
> algorithm:
>
> "2.If the method was called with a second argument ports and that
> argument isn't null, then, if any of the entries in ports are null, if
> any MessagePort ob
On Fri, Jun 10, 2011 at 12:50 PM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
>
>
> >From: Kenneth Russell [mailto:k...@google.com], Sent: Thursday, June 09,
> 2011 11:15 PM
> >On Thu, Jun 9, 2011 at 10:54 PM, Travis Leithead
> > wrote:
> >> Honestly, there's something about this whole
>From: Kenneth Russell [mailto:k...@google.com], Sent: Thursday, June 09, 2011
>11:15 PM
>On Thu, Jun 9, 2011 at 10:54 PM, Travis Leithead
> wrote:
>> Honestly, there's something about this whole discussion that just
>> doesn't feel right.
>>
>>
>>
>> I looks like we're trying to graft-in this n
(Can you please reset your font?)
On Fri, Jun 10, 2011 at 1:54 AM, Travis Leithead <
travis.leith...@microsoft.com> wrote:
> We don’t really need to support JavaScript objects, arrays, complex
> graphs, etc. at all with the new API
>
Strongly disagree. I should be able to transfer objects natu
On Thu, Jun 9, 2011 at 10:54 PM, Travis Leithead
wrote:
> Honestly, there’s something about this whole discussion that just doesn’t
> feel right.
>
>
>
> I looks like we’re trying to graft-in this new concept of transfer of
> ownership into the existing postMessage semantics (i.e., object cloning)
Honestly, there's something about this whole discussion that just doesn't feel
right.
I looks like we're trying to graft-in this new concept of transfer of ownership
into the existing postMessage semantics (i.e., object cloning). Any way I try
to make it work, it just looks like peaches grafted
From: Andrew Wilson [mailto:atwil...@google.com]
Sent: Friday, June 03, 2011 2:15 PM
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking
mailto:jo...@sicking.cc>> wrote:
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell
mailto:k...@google.com>> wrote:
> On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard
> m
On Thu, Jun 9, 2011 at 11:13 AM, Glenn Maynard wrote:
> On Thu, Jun 9, 2011 at 1:28 PM, Andrew Wilson wrote:
> > 1) I'm not completely sure I understand what the new postMessage()
> semantics
> > look like. Since cloning a port is a destructive operation, I like the
> fact
> > that the current p
On Thu, Jun 9, 2011 at 1:28 PM, Andrew Wilson wrote:
> 1) I'm not completely sure I understand what the new postMessage()
semantics
> look like. Since cloning a port is a destructive operation, I like the
fact
> that the current postMessage() API requires the developer to explicitly
pass
> a list
On Wed, Jun 8, 2011 at 6:26 PM, Kenneth Russell wrote:
>
> 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
>
>
So a number of different variations ha
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:
>
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
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 reason
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 lev
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'
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
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 mak
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, h
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,
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 understandin
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
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 we
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
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 exi
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 i
> On Fri, Jun 3, 2011 at 6:02 PM, Jonas Sicking wrote:
>> e) Keep "MessagePort[] ports" the way it is but deprecate it.
>
> 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
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 change
On Fri, Jun 3, 2011 at 2:54 PM, Kenneth Russell wrote:
> On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson wrote:
>>
>>
>> On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking wrote:
>>>
>>> On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
>>> > On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson wrote:
>
>
> On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking wrote:
>>
>> On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
>> > On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
>> >> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov
>> >> wrot
On Fri, Jun 3, 2011 at 2:25 PM, Dmitry Lomov wrote:
> (I am answering on multiple points - I do not want to fork the thread)
>
> On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking wrote:
>>
>> On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
>> > On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard
On Fri, Jun 3, 2011 at 2:15 PM, Andrew Wilson wrote:
>
>
> On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking wrote:
>
>> On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
>> > On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
>> >> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov
>> wrote:
On Fri, Jun 3, 2011 at 1:02 PM, Jonas Sicking wrote:
> On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
> > On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
> >> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov
> wrote:
> >>> a) Recursive transfer lists. Allow arbitrary objects, not on
On Fri, Jun 3, 2011 at 11:37 AM, Kenneth Russell wrote:
> On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
>> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov wrote:
>>> a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
>>> to appear in transfer lists. ArrayBuffers t
On Fri, Jun 3, 2011 at 9:46 AM, Glenn Maynard wrote:
> On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov wrote:
>> a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
>> to appear in transfer lists. ArrayBuffers that are under objects in
>> transfer lists are transferred, ot
On Fri, Jun 3, 2011 at 11:12 AM, Dmitry Lomov wrote:
> a) Recursive transfer lists. Allow arbitrary objects, not only ArrayBuffers,
> to appear in transfer lists. ArrayBuffers that are under objects in
> transfer lists are transferred, others are cloned.
This again causes the same forwards-compa
On Thu, Jun 2, 2011 at 11:44 PM, Dmitry Lomov wrote:
>
>
> On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking wrote:
>
>> On Thu, Jun 2, 2011 at 4:41 PM, David Levin wrote:
>> >
>> >
>> > On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking wrote:
>> >>
>> >> On Thu, Jun 2, 2011 at 2:01 PM, David Levin
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking wrote:
> On Thu, Jun 2, 2011 at 4:41 PM, David Levin wrote:
> >
> >
> > On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking wrote:
> >>
> >> On Thu, Jun 2, 2011 at 2:01 PM, David Levin wrote:
> >> >
> >> >
> >> > On Thu, Jun 2, 2011 at 1:27 PM, Glenn Ma
On Fri, Jun 3, 2011 at 2:44 AM, Dmitry Lomov wrote:
>> Now show me the code needed to send a message which contains one big
>> buffer from you that you want to transfer, along with some data that
>> you got from some other piece of code and which you do not want to
>> modify and which may or may n
On Thu, Jun 2, 2011 at 10:17 PM, Jonas Sicking wrote:
> On Thu, Jun 2, 2011 at 4:41 PM, David Levin wrote:
> >> None of the objects which allow transferring of ownership has children
> >> so this doesn't appear to be a problem at this time. If it indeed does
> >> turn into a problem, it would se
On Thu, Jun 2, 2011 at 4:41 PM, David Levin wrote:
>
>
> On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking wrote:
>>
>> On Thu, Jun 2, 2011 at 2:01 PM, David Levin wrote:
>> >
>> >
>> > On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard wrote:
>> >> port.postMessage({frameBuffer: frame}, {transfer: [fra
On Thu, Jun 2, 2011 at 4:24 PM, Jonas Sicking wrote:
> On Thu, Jun 2, 2011 at 2:01 PM, David Levin wrote:
> >
> >
> > On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard wrote:
> >> port.postMessage({frameBuffer: frame}, {transfer: [frame], ports:
> >> [port]});
>
> There are two properties of this
On Thu, Jun 2, 2011 at 5:30 PM, Glenn Maynard wrote:
> On Thu, Jun 2, 2011 at 5:01 PM, David Levin wrote:
>> It feels like this array of objects given to transfer may complicate (and
>> slow down) both the implementation of this as well as the developer's use of
>> it.
>
> Even with thousands of
On Thu, Jun 2, 2011 at 2:01 PM, David Levin wrote:
>
>
> On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard wrote:
>>
>> On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell wrote:
>> > On Thu, Jun 2, 2011 at 12:53 PM, David Levin wrote:
>> > The desire would be for this change to apply not just to the
>
On Thu, Jun 2, 2011 at 5:01 PM, David Levin wrote:
> It feels like this array of objects given to transfer may complicate (and
> slow down) both the implementation of this as well as the developer's use of
> it.
Even with thousands of objects, creating an array containing them is
quick (and only
On Thu, Jun 2, 2011 at 1:27 PM, Glenn Maynard wrote:
> On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell wrote:
> > On Thu, Jun 2, 2011 at 12:53 PM, David Levin wrote:
> > The desire would be for this change to apply not just to the
> > postMessage method on MessagePort and Worker but also to tha
On Thu, Jun 2, 2011 at 4:16 PM, Kenneth Russell wrote:
> On Thu, Jun 2, 2011 at 12:53 PM, David Levin wrote:
> The desire would be for this change to apply not just to the
> postMessage method on MessagePort and Worker but also to that on
> Window.
I agree--the postMessage interfaces shouldn't d
On Thu, Jun 2, 2011 at 1:13 PM, Boris Zbarsky wrote:
> On 6/2/11 3:53 PM, David Levin wrote:
>
>> The mechanism:
>>
>>* needs to have an intuitive feel for developers,
>>* must preserve backwards compatibility,
>>* should ideally allow the port to function the same regardless of
>>
On Thu, Jun 2, 2011 at 12:53 PM, David Levin wrote:
> In summary, there is a desire for a mechanism to transfer objects (to allow
> for potentially better perf) across a MessagePort.
> The mechanism:
>
> needs to have an intuitive feel for developers,
> must preserve backwards compatibility,
> sho
On 6/2/11 3:53 PM, David Levin wrote:
The mechanism:
* needs to have an intuitive feel for developers,
* must preserve backwards compatibility,
* should ideally allow the port to function the same regardless of
whether the message was cloned or transferred.
I'm not sure what
In summary, there is a desire for a mechanism to transfer objects (to allow
for potentially better perf) across a MessagePort.
The mechanism:
- needs to have an intuitive feel for developers,
- must preserve backwards compatibility,
- should ideally allow the port to function the same re
On Thu, Jun 2, 2011 at 11:54 AM, Ian Hickson wrote:
> On Thu, 2 Jun 2011, ben turner wrote:
>>
>> I interpreted the proposal differently... This is what I envisioned:
>>
>> var bufferToTransfer = /* make ArrayBuffer */;
>> var bufferToCopy = /* make ArrayBuffer */;
>> var worker = /* make Wo
On Thu, 2 Jun 2011, ben turner wrote:
>
> I interpreted the proposal differently... This is what I envisioned:
>
> var bufferToTransfer = /* make ArrayBuffer */;
> var bufferToCopy = /* make ArrayBuffer */;
> var worker = /* make Worker */;
> var message = { buf1: bufferToTransfer, buf2:
On Thu, Jun 2, 2011 at 10:22 AM, ben turner wrote:
> On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
> wrote:
>>
>> This plan requires all objects that want to opt-in to a new
>> transfer-of-ownership (or really
>> any special custom behavior for postMessage) to 1) participate in the
>> special
On Thu, Jun 2, 2011 at 12:58 PM, Travis Leithead
wrote:
> I'm a little concerned about the inherit approach that Ian outlines...
>
> This plan requires all objects that want to opt-in to a new
> transfer-of-ownership (or really any special custom behavior for postMessage)
> to 1) participate in
On Thu, Jun 2, 2011 at 8:25 AM, Jonas Sicking wrote:
> On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russell wrote:
>> On Tue, May 31, 2011 at 3:35 PM, Ian Hickson wrote:
>>> On Tue, 31 May 2011, Kenneth Russell wrote:
Jonas's suggestion of adding another argument to postMessage, and
Gr
On Thu, Jun 2, 2011 at 9:58 AM, Travis Leithead
wrote:
>
> This plan requires all objects that want to opt-in to a new
> transfer-of-ownership (or really
> any special custom behavior for postMessage) to 1) participate in the special
> inheritance
> interface and 2) be isolated from the primary
bapps@w3.org
> Subject: What changes to Web Messaging spec are proposed? [Was: Re: Using
> ArrayBuffer as payload for binary data to/from Web Workers]
>
> What are the specific change(s) to the Web Messaging spec being proposed:
>
> http://dev.w3.org/html5/postmsg/
>
> -A
vis Leithead; g...@google.com; cmar...@apple.com; gl...@zewt.org;
public-webapps@w3.org
Subject: What changes to Web Messaging spec are proposed? [Was: Re: Using
ArrayBuffer as payload for binary data to/from Web Workers]
What are the specific change(s) to the Web Messaging spec being proposed:
http://d
What are the specific change(s) to the Web Messaging spec being proposed:
http://dev.w3.org/html5/postmsg/
-AB
On Jun/2/2011 11:25 AM, ext Jonas Sicking wrote:
On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russell wrote:
On Tue, May 31, 2011 at 3:35 PM, Ian Hickson wrote:
On Tue, 31 May 2011,
On Wed, Jun 1, 2011 at 4:55 PM, Kenneth Russell wrote:
> On Tue, May 31, 2011 at 3:35 PM, Ian Hickson wrote:
>> On Tue, 31 May 2011, Kenneth Russell wrote:
>>>
>>> Jonas's suggestion of adding another argument to postMessage, and
>>> Gregg's generalization to declare it as an array of objects to
On Tue, May 31, 2011 at 3:35 PM, Ian Hickson wrote:
> On Tue, 31 May 2011, Kenneth Russell wrote:
>>
>> Jonas's suggestion of adding another argument to postMessage, and
>> Gregg's generalization to declare it as an array of objects to be
>> transferred rather than copied, sounds good.
>
> We coul
On Tue, 31 May 2011, Kenneth Russell wrote:
>
> Jonas's suggestion of adding another argument to postMessage, and
> Gregg's generalization to declare it as an array of objects to be
> transferred rather than copied, sounds good.
We could change make MessagePort and ArrayBuffer both inherit from
On Tue, May 31, 2011 at 11:33 AM, Travis Leithead
wrote:
>> > > The editors' draft of the typed array spec has been updated with a
>> > > strawman proposal for this zero-copy, transfer-of-ownership behavior:
>> > >
>> > > http://www.khronos.org/registry/typedarray/specs/latest/
>> > >
>> > > Feedb
> > > The editors' draft of the typed array spec has been updated with a
> > > strawman proposal for this zero-copy, transfer-of-ownership behavior:
> > >
> > > http://www.khronos.org/registry/typedarray/specs/latest/
> > >
> > > Feedback would be greatly appreciated. For the purposes of keeping th
On Thu, May 26, 2011 at 8:20 PM, Jonas Sicking wrote:
> On Fri, Apr 22, 2011 at 6:26 PM, Kenneth Russell wrote:
> > On Mon, Mar 7, 2011 at 6:17 PM, Kenneth Russell wrote:
> >> On Mon, Mar 7, 2011 at 5:18 PM, Chris Marrin wrote:
> >>>
> >>> On Mar 7, 2011, at 4:46 PM, Kenneth Russell wrote:
> >
On Fri, Apr 22, 2011 at 6:26 PM, Kenneth Russell wrote:
> On Mon, Mar 7, 2011 at 6:17 PM, Kenneth Russell wrote:
>> On Mon, Mar 7, 2011 at 5:18 PM, Chris Marrin wrote:
>>>
>>> On Mar 7, 2011, at 4:46 PM, Kenneth Russell wrote:
>>>
On Mon, Mar 7, 2011 at 3:54 PM, Glenn Maynard wrote:
>
On Fri, Apr 22, 2011 at 6:26 PM, Kenneth Russell wrote:
> On Mon, Mar 7, 2011 at 6:17 PM, Kenneth Russell wrote:
>> On Mon, Mar 7, 2011 at 5:18 PM, Chris Marrin wrote:
>>>
>>> On Mar 7, 2011, at 4:46 PM, Kenneth Russell wrote:
>>>
On Mon, Mar 7, 2011 at 3:54 PM, Glenn Maynard wrote:
>
On Mon, Mar 7, 2011 at 6:17 PM, Kenneth Russell wrote:
> On Mon, Mar 7, 2011 at 5:18 PM, Chris Marrin wrote:
>>
>> On Mar 7, 2011, at 4:46 PM, Kenneth Russell wrote:
>>
>>> On Mon, Mar 7, 2011 at 3:54 PM, Glenn Maynard wrote:
On Mon, Mar 7, 2011 at 6:05 PM, Chris Marrin wrote:
>
>
On Wed, Mar 9, 2011 at 3:40 PM, Boris Zbarsky wrote:
> On 3/9/11 1:54 PM, Glenn Maynard wrote:
>>
>> Any system with memory protection can interrupt on write, which makes
>> copy-on-write very close to free, as long as you can page-align the
>> buffer.
>
> That's a pretty serious caveat, though.
On 3/9/11 1:54 PM, Glenn Maynard wrote:
Any system with memory protection can interrupt on write, which makes
copy-on-write very close to free, as long as you can page-align the buffer.
That's a pretty serious caveat, though. And you're assuming that memory
meta-operations like "set up a cust
On Wed, Mar 9, 2011 at 1:24 PM, Chris Marrin wrote:
> >> I don't recall if this has been brought up: are there cases where
> >> explicit zero-copy messaging is better than transparent copy-on-write?
> >
> > Transparent copy on write requires that each write do a "should I copy?"
> check, right?
>
On Mar 7, 2011, at 7:12 PM, Glenn Maynard wrote:
> On Mon, Mar 7, 2011 at 9:07 PM, Boris Zbarsky wrote:
> On 3/7/11 8:55 PM, Glenn Maynard wrote:
> I'd expect CanvasPixelArray to allow optimizations that ArrayBuffer
> doesn't, since the implementation can use the native surface format,
> transla
On Mar 7, 2011, at 6:07 PM, Boris Zbarsky wrote:
> On 3/7/11 8:55 PM, Glenn Maynard wrote:
>> I'd expect CanvasPixelArray to allow optimizations that ArrayBuffer
>> doesn't, since the implementation can use the native surface format,
>> translating to RGBA for the script transparently. This can
On Mon, Mar 7, 2011 at 10:12 PM, Glenn Maynard wrote:
> That could be dealt with by adding methods like ArrayBuffer.discard(),
> though...
>
Scratch that--discarding after postMessage is racy, since the other side
could receive the object before the worker calls discard(). The object
needs to b
1 - 100 of 112 matches
Mail list logo
