Re: [whatwg] [Workers] CSP and SharedWorkers

On Wed, Sep 25, 2013 at 8:00 PM, Kyle Huey 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 didn't really r

Re: [whatwg] [Workers] CSP and SharedWorkers

On 26 September 2013 14:57, Jake Archibald 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 for all top-level

Re: [whatwg] [Workers] CSP and SharedWorkers

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 was

Re: [whatwg] [Workers] CSP and SharedWorkers

On Wed, Sep 25, 2013 at 11:00 PM, Kyle Huey wrote: > Thoughts? What happens today for ? The load itself seems to be governed by the parent. Does the policy inherit into it? I feel like workers should work like as they're essentially their own global objects. -- http://annevankesteren.nl/

[whatwg] [Workers] CSP and SharedWorkers

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.

Re: [whatwg] Workers feedback

On Fri, 4 Feb 2011, Glenn Maynard wrote: > On Fri, Feb 4, 2011 at 6:43 PM, Ian Hickson 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 will

Re: [whatwg] Workers feedback

On Mon, Feb 14, 2011 at 5:02 AM, Ian Hickson 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

Re: [whatwg] Workers feedback

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 do

Re: [whatwg] Workers feedback

On Mon, Feb 14, 2011 at 1:37 AM, Ian Hickson wrote: > On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote: > > On Fri, Feb 11, 2011 at 5:45 PM, Ian Hickson wrote: > > > On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote: > > > > > On Fri, 7 Jan 2011, Berend-Jan Wever wrote: > > > > > > > > > > > > 1) To

Re: [whatwg] Workers feedback

On Fri, 11 Feb 2011, Gregg Tavares (wrk) wrote: > On Fri, Feb 11, 2011 at 5:45 PM, Ian Hickson 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 > >

Re: [whatwg] Workers feedback

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 unde

Re: [whatwg] Workers feedback

On Fri, Feb 11, 2011 at 5:45 PM, Ian Hickson 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...? > > > > >

Re: [whatwg] Workers feedback

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

Re: [whatwg] Workers feedback

On Fri, Feb 4, 2011 at 3:43 PM, Ian Hickson 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 d

Re: [whatwg] Workers feedback

On Fri, Feb 4, 2011 at 6:43 PM, Ian Hickson 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 generally pro

[whatwg] Workers feedback

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?

Re: [whatwg] Workers: what should happen when exceeding worker limit?

On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson 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 user agent c

Re: [whatwg] Workers: what should happen when exceeding worker limit?

On Thu, Dec 30, 2010 at 7:11 PM, Ian Hickson 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 limits.) Thi

Re: [whatwg] Workers: what should happen when exceeding worker limit?

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 u

Re: [whatwg] Workers: what should happen when exceeding worker limit?

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

[whatwg] Workers: what should happen when exceeding worker limit?

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 it

Re: [whatwg] Workers: What can be done in a worker after call to close()?

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

Re: [whatwg] Workers: What can be done in a worker after call to close()?

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,

Re: [whatwg] Workers: What can be done in a worker after call to close()?

On Thu, Apr 1, 2010 at 4:40 PM, Drew Wilson wrote: > How does the GC-initiated close() event work in Firefox, in the case of a > fire-and-forget worker? > For example: > foo.html: > > new Worker("forget.js"); > > forget.js: > self.setInterval(function() { ...do something...}, 1000); > In this ca

Re: [whatwg] Workers: What can be done in a worker after call to close()?

How does the GC-initiated close() event work in Firefox, in the case of a fire-and-forget worker? For example: foo.html: new Worker("forget.js"); forget.js: self.setInterval(function() { ...do something...}, 1000); In this case, it seems incorrect to ever fire a close() event until the parent

Re: [whatwg] Workers: What can be done in a worker after call to close()?

On Wed, Mar 31, 2010 at 10:03 AM, ben turner 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 functionality un

Re: [whatwg] Workers: What can be done in a worker after call to close()?

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 Web

Re: [whatwg] Workers: What can be done in a worker after call to close()?

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

Re: [whatwg] Workers: What can be done in a worker after call to close()?

On Tue, Mar 30, 2010 at 5:58 PM, Drew Wilson 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 any time, e.

Re: [whatwg] Workers: What can be done in a worker after call to close()?

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

[whatwg] Workers: What can be done in a worker after call to close()?

Hi! Trying to fix some bugs for Workers, I've got some questions about close() method on WorkerGlobalScope . In particular, the spec seems to imply that after calling close() inside the worker, the JS does not get terminate

Re: [whatwg] Workers and addEventListener

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 addEventLi

Re: [whatwg] Workers and addEventListener

>> 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

Re: [whatwg] Workers and addEventListener

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(); > channel.port1.postMes

Re: [whatwg] Workers and addEventListener

On Thu, 15 Oct 2009, Drew Wilson wrote: > On Wed, Oct 14, 2009 at 3:33 AM, Ian Hickson 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 expli

Re: [whatwg] Workers and addEventListener

On Thu, 15 Oct 2009 19:54:23 +0200, Drew Wilson 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 something more than just r

Re: [whatwg] Workers and addEventListener

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"

Re: [whatwg] Workers and addEventListener

On Wed, Oct 14, 2009 at 3:33 AM, Ian Hickson 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 the port

Re: [whatwg] Workers and addEventListener

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 > onmessage<#handler-messagepo

Re: [whatwg] Workers and addEventListener

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

Re: [whatwg] Workers and addEventListener

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

Re: [whatwg] Workers and addEventListener

On Tue, 29 Sep 2009 09:13:17 +0200, Zoltan Herczeg wrote: Anyway, my qestion is: - should addEventListener enable message transmitting? - Should it do it in all cases, or only when "message" is passed as the first argument I don't think it should. Web Workers should not modify the semanti

[whatwg] Workers and addEventListener

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 MessagePor

Re: [whatwg] "workers" Highlighted

On Thu, 18 Jun 2009 14:50:41 +0200, Smylers 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". That didn'

[whatwg] "workers" Highlighted

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: http://www.whatwg.org/html5#s

Re: [whatwg] Workers and URL origin check

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 U

Re: [whatwg] Workers and URL origin check

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 hand

Re: [whatwg] Workers and URL origin check

On Fri, May 29, 2009 at 12:27 PM, Kristof Zelechovski 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 scripts (all scripts > pr

Re: [whatwg] Workers and URL origin check

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 wo

Re: [whatwg] Workers and URL origin check

On Thu, May 28, 2009 at 9:50 AM, Drew Wilson wrote: > > > On Thu, May 28, 2009 at 1:11 AM, Jonas Sicking wrote: >> >> On Wed, May 27, 2009 at 6:15 PM, Drew Wilson wrote: >> > Along the same lines, I'm wondering why we require a same-domain check >> > for >> > initial worker URLs, but not for scr

Re: [whatwg] Workers and URL origin check

On Thu, May 28, 2009 at 12:05 PM, Dmitry Titov 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 if the final U

Re: [whatwg] Workers and URL origin check

For me it feels the importScripts('foo.js') is a textual #include, while Worker('foo.js') like a call into an enclosed component. :-) It seems inheriting origin and base URLs from parent document may create inconsistency for shared workers since it's unclear which origin and base URL they should i

Re: [whatwg] Workers and URL origin check

On Thu, May 28, 2009 at 1:11 AM, Jonas Sicking wrote: > On Wed, May 27, 2009 at 6:15 PM, Drew Wilson 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 i

Re: [whatwg] Workers and URL origin check

On Wed, May 27, 2009 at 6:15 PM, Drew Wilson 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. So this is the orig

Re: [whatwg] Workers and URL origin check

On Wed, May 27, 2009 at 5:13 PM, Dmitry Titov 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 redirect chain is

Re: [whatwg] Workers and URL origin check

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 c

[whatwg] Workers and URL origin check

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

Re: [whatwg] Workers and queue of events

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? > >

Re: [whatwg] Workers feedback

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 > s

Re: [whatwg] Workers and queue of events

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 thi

Re: [whatwg] Workers and queue of events

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 anothe

Re: [whatwg] Workers and queue of events

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 p

Re: [whatwg] Workers and queue of events

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 i

Re: [whatwg] Workers and queue of events

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 this

Re: [whatwg] Workers and queue of events

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

Re: [whatwg] Workers and queue of events

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 setInt

Re: [whatwg] Workers and queue of events

On Wed, Nov 19, 2008 at 2:08 PM, Dmitry Titov <[EMAIL PROTECTED]> 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 > postM

[whatwg] Workers and queue of events

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?

Re: [whatwg] Workers feedback

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.

[whatwg] Workers feedback

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

Re: [whatwg] Workers feedback

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

Re: [whatwg] Workers feedback

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 ev

Re: [whatwg] Workers feedback

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 wel

Re: [whatwg] Workers feedback

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 con

Re: [whatwg] Workers feedback

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

Re: [whatwg] Workers feedback

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

Re: [whatwg] Workers feedback

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. This

Re: [whatwg] Workers feedback

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 enoug

Re: [whatwg] Workers feedback

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 en

Re: [whatwg] Workers feedback

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 transf

Re: [whatwg] Workers feedback

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

Re: [whatwg] Workers feedback

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?

Re: [whatwg] Workers feedback

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

Re: [whatwg] Workers feedback

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

Re: [whatwg] Workers feedback

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/valid

[whatwg] Workers feedback

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 2

Re: [whatwg] 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

Re: [whatwg] Workers

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

Re: [whatwg] Workers

(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 wor

[whatwg] Workers should implement EventTarget

Only the globalscope is specified to implement EventTarget, the actual Worker should too. / Jonas

Re: [whatwg] workers

2008/9/30 Alexey Proskuryakov <[EMAIL PROTECTED]>: > Not really - it seems to me that they could work for shared workers as well, > but I need to think about it more. Creating/accessing a shared worker could > also create a default port that for use with Worker::postMessage, while all > messages fr

Re: [whatwg] workers

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 need

Re: [whatwg] workers

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 indistingu

Re: [whatwg] workers

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 between

Re: [whatwg] workers

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, whoe

Re: [whatwg] workers

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() met

Re: [whatwg] workers

2008/9/30 Alexey Proskuryakov <[EMAIL PROTECTED]>: > 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

Re: [whatwg] workers

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 m

Re: [whatwg] workers

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::startConversati

Re: [whatwg] workers

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

  1   2   >