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
