On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey m...@kylehuey.com wrote:
Thoughts?
What happens today for iframe? The load itself seems to be governed
by the parent. Does the policy inherit into it? I feel like workers
should work like iframe as they're essentially their own global
objects.
--
The registration of a Service Worker is currently only possible via DOM
call from an HTML document, so it makes sense for registration to be
governed by CSP.
There was some discussion here
https://github.com/slightlyoff/ServiceWorker/issues/46
So script-src would cover registration, but there
On 26 September 2013 14:57, Jake Archibald jaffathec...@gmail.com wrote:
Note, this only covers registration. If http://example.com allows
controllers from http://example.co.uk, and successfully calls
registerServiceWorker(/*, http://example.co.uk/service.js;), that
controller will be used
On Wed, Sep 25, 2013 at 8:00 PM, Kyle Huey m...@kylehuey.com wrote:
It's unclear how SharedWorkers should interact with Content Security
Policies. This came up during code review of the SharedWorker
implementation in Gecko[0]. There was a public-webappsec thread[1] on this
back in May that
It's unclear how SharedWorkers should interact with Content Security
Policies. This came up during code review of the SharedWorker
implementation in Gecko[0]. There was a public-webappsec thread[1] on this
back in May that didn't really reach a conclusion and I'd like to drive
towards one here.
On Fri, 4 Feb 2011, Glenn Maynard wrote:
On Fri, Feb 4, 2011 at 6:43 PM, Ian Hickson i...@hixie.ch wrote:
All workers should run soon, not maybe in the future. Not running a
worker should be an unusual circumstance. Errors that occur in unusual
circumstances aren't errors that authors
On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
On Fri, Feb 11, 2011 at 5:45 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
On Fri, 7 Jan 2011, Berend-Jan Wever wrote:
1) To give WebWorkers access to the DOM API so they can create their
On Mon, Feb 14, 2011 at 1:37 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
On Fri, Feb 11, 2011 at 5:45 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
On Fri, 7 Jan 2011, Berend-Jan Wever wrote:
1)
On Mon, 14 Feb 2011, Gregg Tavares (wrk) wrote:
Web pages do not run in a different thread.
Oh, sorry. I meant they run in a different process. At least in some
browsers.
The goal here is interoperability with all browsers, not just some.
I guess I don't understand. There
On Mon, Feb 14, 2011 at 5:02 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 14 Feb 2011, Gregg Tavares (wrk) wrote:
Web pages do not run in a different thread.
Oh, sorry. I meant they run in a different process. At least in some
browsers.
The goal here is
On Fri, Feb 4, 2011 at 3:43 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 16 Oct 2010, Samuel Ytterbrink wrote:
*What is the problem you are trying to solve?*
To create sophisticated single file webpages.
That's maybe a bit vaguer than I was hoping for when asking the question.
:-)
Why
On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
On Fri, 7 Jan 2011, Berend-Jan Wever wrote:
1) To give WebWorkers access to the DOM API so they can create their
own elements such as img, canvas, etc...?
It's the API itself that isn't thread-safe, unfortunately.
I didn't see the
On Fri, Feb 11, 2011 at 5:45 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote:
On Fri, 7 Jan 2011, Berend-Jan Wever wrote:
1) To give WebWorkers access to the DOM API so they can create their
own elements such as img, canvas, etc...?
It's
I'll mention that the Chrome team is experimenting with something like this
(as a Chrome extensions API) - certain extensions will be able to do:
window.open(my_bg_page.html, name, background);
...and the associated window will be opened offscreen. They share a process
with other pages under
On Sat, 16 Oct 2010, Samuel Ytterbrink wrote:
*What is the problem you are trying to solve?*
To create sophisticated single file webpages.
That's maybe a bit vaguer than I was hoping for when asking the question. :-)
Why does it have to be a single file? Would multipart MIME be acceptable?
A
On Fri, Feb 4, 2011 at 6:43 PM, Ian Hickson i...@hixie.ch wrote:
My point is from a black-box perspective, one can never firmly say that
it's not just the browser being slow to start the thread. And we can't
disallow the browser from being slow.
I don't think a black-box test suite can ever
On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson i...@hixie.ch wrote:
That's a hardware limitation, and as such is something we tend to leave up
to the user agents. In practice, it's often the case that user agents are
very constrained in how they can deal with hardware limitations (e.g. if
the
On Thu, 23 Sep 2010, Ivan Kozik wrote:
What should happen when instantiating a Worker that cannot be started
because of the limit on the number of workers?
That's a hardware limitation, and as such is something we tend to leave up
to the user agents. In practice, it's often the case that
On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson i...@hixie.ch wrote:
I guess the simplest answer is don't use more than 16 workers. There's
really not much point in doing so anyway, since most systems don't have 16
cores today. (This will naturally change in the future, but then so will
the
What should happen when instantiating a Worker that cannot be started
because of the limit on the number of workers? Chrome 6 and Chromium
7.0.532.0 (60255) put the 17th worker in a queue, to be created when
some existing worker terminates. This queue seems to be limitless in
size (or at least
Thanks for the feedback! I'd love to know more about your use case (if
possible), since it may motivate further thinking on these limits...
Indeed, the option of immediately throwing was also considered. It didn't
look obviously better for the following reasons (I may forget something, but
that's
On Wed, Mar 31, 2010 at 10:03 AM, ben turner bent.mozi...@gmail.com wrote:
Hi,
When implementing the close() function for Firefox we chose to set the
closing flag and clear pending events only. As the worker script is
calling close() on itself we figured that the worker should retain
maximum
How does the GC-initiated close() event work in Firefox, in the case of a
fire-and-forget worker?
For example:
foo.html:
script
new Worker(forget.js);
/script
forget.js:
self.setInterval(function() { ...do something...}, 1000);
In this case, it seems incorrect to ever fire a close() event
On Thu, Apr 1, 2010 at 4:40 PM, Drew Wilson atwil...@google.com wrote:
How does the GC-initiated close() event work in Firefox, in the case of a
fire-and-forget worker?
For example:
foo.html:
script
new Worker(forget.js);
/script
forget.js:
self.setInterval(function() { ...do
Thanks Jonas!
So there is somewhat of a consensus on close() to effectively let a worker
run normally until the exit from the current JS fragment. It makes sense for
us as well.
I think the only change to the spec here would be the removal of the 3rd
line in the description of what close() does,
On Thu, 1 Apr 2010, Dmitry Titov wrote:
I think the only change to the spec here would be the removal of the 3rd
line in the description of what close() does, so the ports are still
functional, at least for posting from the worker: [...]
I'm fine with doing this.
Not sure about onclose
Hi,
When implementing the close() function for Firefox we chose to set the
closing flag and clear pending events only. As the worker script is
calling close() on itself we figured that the worker should retain
maximum functionality until it has finished execution (otherwise it
could just not call
I see, thanks for the details!
This makes sense - you let the worker run unrestricted (ports still send
messages, sync API work) until it exits JS code. It is one of two
possibilities I though of as well (run unrestricted while in JS or immediate
termination).
BTW, the current Worker spec and
Hi!
Trying to fix some bugs for Workers, I've got some questions about close()
method on
WorkerGlobalScopehttp://www.whatwg.org/specs/web-workers/current-work/#workerglobalscope
.
In particular, the spec seems to imply that after calling close() inside the
worker, the JS does not get terminated
I'll note that the spec gives the UA an significant amount of latitude about
its behavior after close() is called:
User agents may invoke the kill a worker #kill-a-worker processing model
on a worker at any time, e.g. in response to user requests, in response to
CPU quota management, or when a
On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson atwil...@google.com wrote:
I'll note that the spec gives the UA an significant amount of latitude
about its behavior after close() is called:
User agents may invoke the kill a worker#127b1baa1cefaebf_kill-a-worker
processing model on a worker at
On Fri, 16 Oct 2009, Zoltan Herczeg wrote:
I would not be opposed to changing the spec to include enabling a
port's message queue when addEventListener(message) is invoked.
I'm reluctant to make addEventListener() do magic.
we have two choices:
- extend addEventListener
- fix
I would not be opposed to changing the spec to include enabling a port's
message queue when addEventListener(message) is invoked.
I'm reluctant to make addEventListener() do magic.
we have two choices:
- extend addEventListener
- fix the Shared Worker example on the whatwg site to call
On Wed, Oct 14, 2009 at 3:33 AM, Ian Hickson i...@hixie.ch wrote:
There's no start() to call, since there's no explicit pointer to the
MessagePort in dedicated workers.
The example in the worker spec refers to shared workers, which *do* have an
explicit port, and do not automatically start
To be absolutely clear (since there's some confusion about whether we are
talking about explicit MessagePorts, or about implicit ports for dedicated
workers).
Are you saying that this:
var channel = new MessageChannel();
channel.port1.postMessage(hi mom);
channel.port2.addEventListener(message,
On Thu, 15 Oct 2009 19:54:23 +0200, Drew Wilson atwil...@google.com
wrote:
I would not be opposed to changing the spec to include enabling a port's
message queue when addEventListener(message) is invoked.
FWIW, I would be opposed to any change to addEventListener() that makes it
do
On Thu, 15 Oct 2009, Drew Wilson wrote:
On Wed, Oct 14, 2009 at 3:33 AM, Ian Hickson i...@hixie.ch wrote:
There's no start() to call, since there's no explicit pointer to the
MessagePort in dedicated workers.
The example in the worker spec refers to shared workers, which *do* have
an
On Thu, 15 Oct 2009, Drew Wilson wrote:
To be absolutely clear (since there's some confusion about whether we
are talking about explicit MessagePorts, or about implicit ports for
dedicated workers). Are you saying that this:
var channel = new MessageChannel();
On Tue, 29 Sep 2009, Zoltan Herczeg wrote:
In WebKit implementation of MessagePort the addEventListener(message,
...) does not enable the transmitting of messages. All messages are
actually discarded until a dummy function is assigned to onmessage.
That is a bug. The port message queue is
On Tue, 29 Sep 2009, Drew Wilson wrote:
The intent of the spec is fairly clear that addEventListener(message)
should not start the message queue dispatch - only setting the onmessage
attribute does that:
The first time a MessagePort #messageport object's
Hi all,
I am Zoltan Herczeg from University of Szeged, Hungary. I am a member of a
team who working on WebKit browser engine.
In this bug report: https://bugs.webkit.org/show_bug.cgi?id=29801 , Alexey
suggested me that I should contact you about my qestion.
In WebKit implementation of
The intent of the spec is fairly clear that addEventListener(message)
should not start the message queue dispatch - only setting the onmessage
attribute does that:
The first time a MessagePort #messageport object's
onmessage#handler-messageport-onmessage IDL
attribute is set, the port's port
In the 'Design Notes' section the word workers has a thick pale green
underline. It isn't apparent what this is signifying. Moving the mouse
over it reveals it isn't a link, but a tool-tip appears -- with the text
Worker. That didn't really elucidate matters:
On Thu, 18 Jun 2009 14:50:41 +0200, Smylers smyl...@stripey.com wrote:
In the 'Design Notes' section the word workers has a thick pale green
underline. It isn't apparent what this is signifying. Moving the mouse
over it reveals it isn't a link, but a tool-tip appears -- with the text
Worker.
On Wed, 27 May 2009, Dmitry Titov wrote:
I have a question about URL origin check for Workers: the spec, in
4.8.2, mandates a check for the Worker URL to be the 'same origin' with
the parent document's URL. At the same time, 4.2 says the origin of the
worker is derived later from the URL
On Fri, May 29, 2009 at 12:27 PM, Kristof Zelechovski
giecr...@stegny.2a.pl wrote:
Inserting a SCRIPT element is not equivalent to a server-side include. It
is more like linking to an object file. In particular, substitution macros
(e.g. CONST in BASIC) in one script do not apply other
I was wrong: CONST values and conditional compilation variables land as
properties of the window, which means they are unavailable to other scripts
only if the defining script is external and deferred.
Still, I do not think this behavior is mandatory for run-time; there may be
symbols that are
Inserting a SCRIPT element is not equivalent to a server-side include. It
is more like linking to an object file. In particular, substitution macros
(e.g. CONST in BASIC) in one script do not apply other scripts (all scripts
present have already been parsed, and applying them to future scripts
On Wed, May 27, 2009 at 5:13 PM, Dmitry Titov dim...@chromium.org wrote:
Should the spec simply require the redirected, final URLs to be checked
against parent's and reject the script if redirection results in a different
origin?
I suspect the correct behavior is to make sure every URL on the
On Wed, May 27, 2009 at 6:15 PM, Drew Wilson atwil...@google.com wrote:
Along the same lines, I'm wondering why we require a same-domain check for
initial worker URLs, but not for script imported via importScripts().
This is because workers run in a security context of the initial
worker URL.
On Thu, May 28, 2009 at 1:11 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 27, 2009 at 6:15 PM, Drew Wilson atwil...@google.com wrote:
Along the same lines, I'm wondering why we require a same-domain check
for
initial worker URLs, but not for script imported via importScripts().
On Thu, May 28, 2009 at 12:05 PM, Dmitry Titov dim...@chromium.org wrote:
Returning to the the narrower original question, what should we do with
redirects during worker loads?
- should we abort load if any URL in the redirect chain is from different
origin?
Yes.
- should we only abort load
On Thu, May 28, 2009 at 9:50 AM, Drew Wilson atwil...@google.com wrote:
On Thu, May 28, 2009 at 1:11 AM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 27, 2009 at 6:15 PM, Drew Wilson atwil...@google.com wrote:
Along the same lines, I'm wondering why we require a same-domain check
for
Hi WHATWG!
I have a question about URL origin check for Workers: the spec, in 4.8.2,
mandates a check for the Worker URL to be the 'same origin' with the parent
document's URL. At the same time, 4.2 says the origin of the worker is
derived later from the URL represented by the 'location' object of
Along the same lines, I'm wondering why we require a same-domain check for
initial worker URLs, but not for script imported via importScripts(). Seems
like we ought to have workers inherit the origin of the script context that
invoked the Worker constructor, but allow the script URL passed to the
On Tue, 18 Nov 2008, Alexey Proskuryakov wrote:
[...] If you implement the actual IPC using, say, a Unix socket, then
you can just pass the actual socket along and do the same thing
without blocking.
This is an interesting point. I do not know enough about how Unix domain
sockets are
On Tue, 18 Nov 2008, Dmitry Titov wrote:
Pages communicate with their workers (dedicated) via queue of
events.
What happens if the queue gets more and more events queued (as a result
of postMessage or timer callbacks) and the worker thread does not
consume them fast enough?
-
On Wed, Nov 19, 2008 at 7:43 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
And if it becomes a problem we might in a future version be able to add
something like a 'messagepostfailed' event that is fired on the sending port
in case a message failed to reach its target for one reason or another.
Nov 19, 2008, в 12:55 PM, Robert O'Callahan написал(а):
And if it becomes a problem we might in a future version be able to
add something like a 'messagepostfailed' event that is fired on the
sending port in case a message failed to reach its target for one
reason or another.
I don't
on 18.11.2008 06:43, Ian Hickson at [EMAIL PROTECTED] wrote:
I'd be more that happy with a separate interface if the objects actually
behaved differently. One example of a good reason to have separate
interfaces was recently proposed here: shared workers should outlive
their creators. This is
Pages communicate with their workers (dedicated) via queue of
eventshttp://www.whatwg.org/specs/web-workers/current-work/#the-queue
.
What happens if the queue gets more and more events queued (as a result of
postMessage or timer callbacks) and the worker thread does not consume them
fast enough?
On Wed, Nov 19, 2008 at 2:08 PM, Dmitry Titov [EMAIL PROTECTED] wrote:
Pages communicate with their workers (dedicated) via queue of
eventshttp://www.whatwg.org/specs/web-workers/current-work/#the-queue .
What happens if the queue gets more and more events queued (as a result of
postMessage
It does seem like OOM indeed but it may be different because with multiple
threads it's much easier to get into effects like this, you don't need to
allocate a lot of objects.For example, lets say there is something like
this:
function computeStuff() { ... } // takes 100ms to compute stuff
On Wed, Nov 19, 2008 at 4:44 PM, Dmitry Titov [EMAIL PROTECTED] wrote:
It does seem like OOM indeed but it may be different because with multiple
threads it's much easier to get into effects like this, you don't need to
allocate a lot of objects.
You're not allocating JS objects but you are
Ok, it makes sense for OOM to treat it as other OOM cases.
If I may ask your opinion about related thing: SharedWorkers potentially
would run cross-process. IPC can stop/stuck for many reasons, taret process
can die in the midflight (killed by the user from TaskManager for example).
I guess in
On Tue, Nov 18, 2008 at 10:09 PM, Dmitry Titov [EMAIL PROTECTED] wrote:
Ok, it makes sense for OOM to treat it as other OOM cases.
If I may ask your opinion about related thing: SharedWorkers potentially
would run cross-process. IPC can stop/stuck for many reasons, taret process
can die in the
Aaron Boodman wrote:
On Tue, Nov 18, 2008 at 10:09 PM, Dmitry Titov [EMAIL PROTECTED] wrote:
Ok, it makes sense for OOM to treat it as other OOM cases.
If I may ask your opinion about related thing: SharedWorkers potentially
would run cross-process. IPC can stop/stuck for many reasons, taret
Summary:
* added window.location.resolveURL(). I haven't added it to the Location
in Workers -- should I?
* no other normative changes.
On Thu, 13 Nov 2008, Jonas Sicking wrote:
Actually, i think we should remove the location accessor as well. I
can't think of a common enough use
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
Nov 14, 2008, в 2:30 AM, Ian Hickson написал(а):
I believe that the idea that the API for shared and dedicated workers
should be the same is misguided. The spec used to make the two cases
identical. The result was confusion, and the dedicated case was much
more
complex than necessary.
On Fri, Nov 14, 2008 at 9:00 AM, Jonas Sicking [EMAIL PROTECTED] wrote:
Oh?! Then I understand even less what the use case is. This is something
that doesn't exist for script and i've never heard anyone ask for it
(granted, that is not proof that no one wants it).
a script can figure out where
Nov 14, 2008, в 10:00 AM, Jonas Sicking написал(а):
What are the use cases? Also note that we can't use it with shared
workers since they can be connected to several pages from
different uris.
It returns the script's URL, not the page's.
Oh?! Then I understand even less what the use case
Ian,
Thanks for taking the time to read and understand all the feedback.
Although this is not my most preferred design for the API, I can live
with it. I'm happy that we removed startConversation(). I think that
was just extra complexity on top of an already large API.
As for putting forward
On Thu, Nov 13, 2008 at 10:17 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Aaron Boodman wrote:
On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 13 Nov 2008, Jonas Sicking wrote:
Actually, i think we should remove the location accessor as well. I
can't think of a
Alexey Proskuryakov wrote:
Nov 14, 2008, в 10:00 AM, Jonas Sicking написал(а):
What are the use cases? Also note that we can't use it with shared
workers since they can be connected to several pages from different
uris.
It returns the script's URL, not the page's.
Oh?! Then I understand
On Wed, Nov 12, 2008 at 3:35 PM, Ian Hickson [EMAIL PROTECTED] wrote:
(cc'ed whatwg -- sorry if that wasn't what you intended)
On Wed, 27 Aug 2008, Michael Nordman wrote:
Is it possible for a worker (shared or dedicated) to reload itself?
Not currently.
For dedicated workers,
On Thu, 13 Nov 2008, David Levin wrote:
I don't really see the use case for self-reloading. Do scripts
self-reload in general?
For people who want to update script in SharedWorker, could they do it
by making the SharedWorker merely a shell?
The SharedWorker would create a Worker to
I haven't written a summary of changes because this is a rather involved
issue and I'd like everyone who has an opinion to actually read this.
I missed a few e-mails sent in the last few hours in this reply, as I
started this yesterday. I'll read and respond to those in a bit.
On Thu, 28 Aug
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
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
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
On Thu, 13 Nov 2008, Jonas Sicking wrote:
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.
I added that one becase Aaron asked for it. Aaron?
--
On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 13 Nov 2008, Jonas Sicking wrote:
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
On Thu, 13 Nov 2008, Jonas Sicking wrote:
Aaron Boodman wrote:
On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 13 Nov 2008, Jonas Sicking wrote:
Actually, i think we should remove the location accessor as well. I
can't think of a common enough use case
Aaron Boodman wrote:
On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 13 Nov 2008, Jonas Sicking wrote:
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
Ian Hickson wrote:
On Thu, 13 Nov 2008, Jonas Sicking wrote:
Aaron Boodman wrote:
On Thu, Nov 13, 2008 at 8:45 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 13 Nov 2008, Jonas Sicking wrote:
Actually, i think we should remove the location accessor as well. I
can't think of a common enough
(cc'ed whatwg -- sorry if that wasn't what you intended)
On Wed, 27 Aug 2008, Michael Nordman wrote:
I see... in that case, consider renaming the owner invoked
worker.close() method to use a different verb than self.close()...
worker.stop() or worker.terminate() or worker.kill() or
Only the globalscope is specified to implement EventTarget, the actual
Worker should too.
/ Jonas
Sep 24, 2008, в 10:38 PM, Aaron Boodman написал(а):
interface DedicatedWorker : Worker {
I've been trying to understand the difference between SharedWorker and
DedicatedWorker interfaces. Besides the ability to pick an existing
worker by name, are there any other semantic differences? I
Sep 30, 2008, в 7:19 PM, Aaron Boodman написал(а):
I'm of the opinion that there should be as little difference as
possible, to lower the amount of API to learn. Therefore in my
preferred proposal, the only difference between SharedWorker and
DedicatedWorker is that the latter has a close()
2008/9/30 Alexey Proskuryakov [EMAIL PROTECTED]:
I'm not sure it's so good in the case of dedicated workers either, as they
can be used from other contexts via additional message ports. The close()
method could just close the default port.
Sure, but in order for that to have happened, whoever
Sep 30, 2008, в 8:46 PM, Aaron Boodman написал(а):
close() was added so that you could forcibly kill a worker. For
example, if you are searching a large set with many workers, you may
want to kill them once one finds a match.
...
So I think it is useful to have a conceptual difference
2008/9/30 Alexey Proskuryakov [EMAIL PROTECTED]:
Hmm... So this is more about how you use the interface, not what the object
behind it is. If one chooses to never call close() on a shared worker (or,
say, sets myWorker.close to null right after invoking constructor), it
becomes
Sep 30, 2008, в 9:11 PM, Aaron Boodman написал(а):
Do you have any thoughts on the extra API on dedicated workers
proposed by Jonas (DedicatedWorker::sendMessage,
DedicatedWorkerGlobalScope::onmessage)?
Not really - it seems to me that they could work for shared workers as
well, but I
Hi Guys,
Sorry about the slow feedback, has been on vacation most of the time.
So first off I don't think we can remove the ability to pass
MessagePorts around. This ability exists in Window.postMessage already
per spec so nothing that the workers spec does can change that. Also, if
we think
On Wed, Sep 24, 2008 at 6:26 PM, Jonas Sicking [EMAIL PROTECTED] wrote:
Sorry about the slow feedback, has been on vacation most of the time.
np.
So first off I don't think we can remove the ability to pass
MessagePorts around. This ability exists in Window.postMessage already
per spec so
On Wed, Sep 24, 2008 at 8:27 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
In the current design, there are three separate mechanisms to connect
to and communicate with a worker:
a) DedicatedWorker::sendMessage() + DedicatedWorkerGlobalScope::onmessage
b) DedicatedWorker::startConversation() +
Ping? Thoughts? Anyone?
Jonas, I know you are the one most likely to be affected by this in
the near term. Thoughts?
I know you are generally in favor of something close to the current
Gears API, and generally against the concept of MessagePorts.
But I think introducing a MessagePort object is
Thinking about this some more, having the port convenience
properties gets confusing when there are multiple clients sending
messages, and doesn't make a whole lot of sense with shared workers.
I think we should just get rid of these. It only adds one line of code
to the simple case. Also, I
I like this a lot. +1 to making connect() always explicit. Implicit
creation of ports led to many rough edges.
I think your proposal nearly works for window.postMessage() too. If
you move 'onconnect' and 'connect()' into a MessageReceiver interface
[better name TBD], and make Worker and Window
1 - 100 of 152 matches
Mail list logo
