- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Mon, 17 Dec 2012 17:01:10 +0000
- To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
- Cc: "public-audio@w3.org" <public-audio@w3.org>
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). -- Marcos Caceres
Received on Monday, 17 December 2012 17:01:39 UTC