W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: [Web MIDI API] Examples and a serializer

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Mon, 17 Dec 2012 19:28:22 +0200
Message-ID: <CAJhzemXWv23Me6sf3JcD8TcVZjdsfcHOwiy96To9OFAQyJi=3A@mail.gmail.com>
To: Marcos Caceres <marcosscaceres@gmail.com>
Cc: "public-audio@w3.org" <public-audio@w3.org>
On Mon, Dec 17, 2012 at 7:01 PM, Marcos Caceres <marcosscaceres@gmail.com>wrote:

> On Monday, December 17, 2012 at 4:44 PM, Jussi Kalliokoski wrote:
> > Now, if we had a serializer and it worked like I think it does, we'd
> have a possible backwards compatibility issue introducing this
> functionality, because the port would have been previously a plain JS
> object whereas now it would be a MIDIPort instance. Not that it's very
> likely that we'd have a backwards-compatibility issue like this. :D
> Asked in #WHATG:
> marcos: Peoples, quick question... can adding a WebIDL serializer to an
> object cause conflicts with Web Workers?
> http://lists.w3.org/Archives/Public/public-audio/2012OctDec/0722.html
> Ms2ger: marcosc, no, that's nonsense
> Ms2ger: If input is a host object (e.g. a DOM node)
> Ms2ger: Throw a DataCloneError exception and abort the overall structured
> clone algorithm.
> marcosc: right, that's what I thought
> marcosc: thanks Ms2ger :)
> ==
> Our Input (MIDIPort) is a host object, so it can be treated as a
> structured clone. So I think we are sweet there. However, we need to look
> at how to specify that properly.
> Need to find some examples of things that can be passed around safely to
> worker contexts (I've little experience with workers, but happy to help do
> the research if you point me in the right direction).

Ok, great news! I've added a bug for this:

Transferables are defined here:
AFAIK currently only implemented for ArrayBuffers, but also in the
proposal Hixie made for Canvas in Web Workers, canvas contexts would be
transferable. I don't know of any precedents for copyable host objects. :/
But that would be preferable in our case, since ports with read access have
only read access and ports with write access have only write access, so I
can't think of possible race conditions.

Received on Monday, 17 December 2012 17:28:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:14 UTC