On Tue, 30 Mar 2010 23:09:49 +0100, Ian Hickson <i...@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
