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)? If you
can't rely on a cleanup then it becomes necessary to have some kind of
repair/validation sequence run on the data next time it is accessed to
check if it's valid. If you can do that then you didn't really need a
cleanup anyway. As far as I can tell the "user-agent specified amount of
time" is going to be a major source of hard-to-spot, hard-to-test bugs
(since full testing probably involves closing and killing browsing
contexts in different ways followed by a login sequence and several page
navigations to get back to the page). I can see authors maybe performing
these tests in IE but not across a range of browsers and computer
specifications.
The spec really needs to make a decision here. Either consistently
provide no cleanup window or make it a requirement to provide a fixed
number of seconds, which is still unreliable but at least within a
smaller margin. Failure to do so will impact heavily on users of less
popular browsers.
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. Since the whole point of workers is
presumably the processing of large datasets then a reliable and
low-overhead means of passing these sets between workers and main
threads (without resorting to SQL, XMLHttpRequest or other indirection)
is an essential function.
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.
Shannon
