I've made createWorker() and createNamedWorker() return Worker objects
with a 'port' attribute that represents the original message port.
I've removed the 'utils' object and put all the APIs back onto the global
scope.
I've changed importScript() to importScripts() and made it take any number
One solution I thought about is to have a base interface such as:
interface MessagePort {
void postMessage(...);
attribute EventListener onmessage;
...
}
Then have
interface Worker : MessagePort {
bool isShared();
worker specific stuff
}
interface PipePort : MessagePort {
On Fri, 8 Aug 2008, Jonas Sicking wrote:
I.e. we wouldn't allow a Worker to be passed to postMessage, but the
object returned from myPipe.port1 would be allowed.
I strongly disagree with the idea of making communication channels with
workers be a second class citizen in terms of being able
Jeremy Doig wrote:
how would this work (say) for different avc profile levels and
features (eg: PAFF support) ?
I don't think that's our problem. The details of determining a type name
for a given file should be in another standard, it should not be in HTML
5. All HTML 5 has to do is delegate
Dave Singer wrote:
I think this is a good idea, but one rapidly runs into the problems
talked about in the 'bucket' RFC, notably that there is not a
universal language for naming codecs (4ccs etc). But it's proved
useful in the past.
In general, the source fallbacks are also a way to
So the API I'm proposing is the following:
[NoInterfaceObject] interface WorkerFactory {
Worker createWorker(in DOMString scriptURL);
Worker createSharedWorker(in DOMString name, in DOMString scriptURL);
};
interface Worker {
boolean postMessage(in DOMString message);
boolean
On Fri, 8 Aug 2008, Jonas Sicking wrote:
So the API I'm proposing is the following:
This seems to be a strict subset of what the spec has now; the only
difference being that there's no easy way to create a worker and then pass
it to someone else to take care of, and there seems to be no easy
Ian Hickson wrote:
On Fri, 8 Aug 2008, Jonas Sicking wrote:
So the API I'm proposing is the following:
This seems to be a strict subset of what the spec has now; the only
difference being that there's no easy way to create a worker and then pass
it to someone else to take care of, and there
On Fri, 8 Aug 2008, Jonas Sicking wrote:
(We might want to add an onconnect property to WorkerGlobalScope,
but it doesn't seem strictly needed)
How else would you connect to a shared worker?
That is done at an application level. For example:
worker = createSharedWorker(foo,
This is something that have been in the back of my brain for a few days:
How do we deal with the user navigating a way from a page if there's a
Worker in the middle of some very long running script?
First off, please notice that this discussion is 100% orthogonal to the
communications API
Ian Hickson wrote:
On Fri, 8 Aug 2008, Jonas Sicking wrote:
(We might want to add an onconnect property to WorkerGlobalScope,
but it doesn't seem strictly needed)
How else would you connect to a shared worker?
That is done at an application level. For example:
worker =
Jonas Sicking wrote:
Ian Hickson wrote:
On Fri, 8 Aug 2008, Jonas Sicking wrote:
(We might want to add an onconnect property to WorkerGlobalScope,
but it doesn't seem strictly needed)
How else would you connect to a shared worker?
That is done at an application level. For example:
worker =
On Fri, 8 Aug 2008, Jonas Sicking wrote:
worker = createSharedWorker(foo, bar.js);
worker.addEventListener(message, handler, false);
worker.postMessage(wassup dude, i just connected);
How would the worker distinguish that from the original parent
sending the same message?
On Fri, 8 Aug 2008, Jonas Sicking wrote:
This is something that have been in the back of my brain for a few days:
How do we deal with the user navigating a way from a page if there's a
Worker in the middle of some very long running script?
Right now the spec says that closing becomes true,
On Sat, Aug 9, 2008 at 7:01 AM, Jonas Sicking [EMAIL PROTECTED] wrote:
I do want to be agressive with killing workers when the user leaves a page
since that makes for better user experience. However I'm also worried about
stopping scripts halfway through breaking things and leaving the site
Hi,
Could it not be set that a there is a maximum execution time for any workers
that are still active, definable by the browser but with a suggested value of
say 1000milliseconds in the spec, any processing that takes longer than this is
killed, but gives the option for well built scripts
http://www.whatwg.org/specs/web-apps/current-work/#createpattern
Notes that:
The first argument gives the image to use as the pattern (either an
HTMLImageElement or an HTMLCanvasElement). Modifying this image after
calling the createPattern() method must not affect the pattern.
What does this
Nevermind:
If the image argument is an HTMLImageElement object whose complete
attribute is false, then the implementation must raise an
INVALID_STATE_ERR exception.
-eric
On Fri, Aug 8, 2008 at 5:03 PM, Eric Seidel [EMAIL PROTECTED] wrote:
On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote:
I'd like to put this back on the list, and it doesn't contain anything
personal, so I'm taking the liberty here.
I'm not sure what you mean by in the binding.
I meant
19 matches
Mail list logo
