- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 01 Apr 2010 17:04:22 +0100
On Tue, 30 Mar 2010 23:09:49 +0100, Ian Hickson <ian at hixie.ch> wrote: >> Personally my guess it's more likely that they really wanted to. > > I have no idea which is more likely. The only use case I'm aware of is > passing an <img> in, and for that there isn't really a fallback position, > so it doesn't matter if we send null or throw an exception. It does matter because if you send null, the worker has to respond that it got null so the script can do what it wants on the main thread, which makes the operation async and means the worker script needs logic for the non-supported case. It's more convenient to catch an exception and do what you want directly, and have the worker script only care about the supported case. This is actually the exact same problem as what we have now, moving from string based to structured clone. In order to test structured clone support, you have to send a message back and forth. I think it would have been better if non-strings threw an exception from the start, but it's too late to change it now. A use case I had with structured clone is posting three ImageData objects where the worker compares the pixels of two of them and puts the difference on the third and posts that one back. I do it in a worker because it's a heavy operation for big images and I needed to keep the timing correct for events in the main thread. If workers isn't supported, I did the operation later when the timing of events didn't matter. I didn't make it detect support for workers but lack of structured clone because it seemed too annoying to implement. -- Simon Pieters Opera Software
Received on Thursday, 1 April 2010 09:04:22 UTC