[whatwg] Workers feedback

[Jonas Sicking]

Ian Hickson wrote:
> On Fri, 14 Nov 2008, Shannon wrote:
>> I don't see any value in the "user-agent specified amount of time" delay 
>> in stopping scripts. How can you write cleanup code when you have no 
>> consistency in how long it gets to run (or if it runs at all)?
> 
> The "user-agent specified amount of time" delay is implemented by every 
> major browser for every script they run today.
> 
> How can people write clean code when they have no consistency in how long 
> their scripts will run (or if they will run at all)?
> 
> Why is this any different?

For what it's worth we set all "user-agent specified amount of time" 
times as close to 0 as we can in our implementation. There's always a 
tiny amount of delay in cross-thread communication, in the order of 
fractions of a second.

>> The specification for message ports is still limited to strings. If no 
>> effort is going to be made to allow numbers, arrays, structs and binary 
>> data then I'd suggest Workers be given functions to 
>> serialise/deserialise these objects.
> 
> We're going to add "JSON-serialisable data" support in due course. I'd 
> rather get the rest of the API nailed down first though.

For what it's worth we support the ECMAScript JSON object inside the 
worker (along with things like Math and Date) which means that you can 
manually JSON-ify you objects when communicating.

>> WorkerUtils does not implement document.cookie. I imagine this would be 
>> very useful in conjunction with cleanup code to flag if a cleanup 
>> operation failed to complete. Storage and Database interfaces are too 
>> heavy for the purpose of simple data like this.
> 
> It's not clear which document the cookie would be for. localStorage is 
> as light-weight than cookies (lighter-weight, arguably), though, so that 
> should be enough, no?

If you really need cookie information you can always call postMessage 
and ask for it.

Actually, i think we should remove the location accessor as well. I 
can't think of a common enough use case that warrants an explicit API. 
You can always transfer the data through postMessage.

/ Jonas