896860 - Allow FrameWorkers to create real Workers

Status: RESOLVED FIXED

(Firefox Graveyard :: SocialAPI, defect)

Description

[Mark Hammond [:markh] [:mhammond]]

Gavin suggested we should expose the ability for FrameWorkers to create (real) subworkers.  In effect, this mean that a FrameWorker should be able to do "new Worker()".

Comment 1

[Mark Hammond [:markh] [:mhammond]]

FYI, given there was some offline discussion about this possibly enabling a web-only solution for talkilla, it should be noted that Chrome does *not* support subworkers - http://crbug.com/31666 (but obviously it doesn't support FrameWorkers either ;)

Comment 2

[Mark Hammond [:markh] [:mhammond]]

Attachment: 896860-worker.patch

While waiting for try and local build, I knocked this up and it all seems to work fine.  It's on top of bug 891218 - but if at all possible during development, keeping it that way is probably good for everyone :)

Comment 3

[Florian Quèze [:florian]]

(In reply to Mark Hammond (:markh) from comment #1)
> FYI, given there was some offline discussion about this possibly enabling a
> web-only solution for talkilla, it should be noted that Chrome does *not*
> support subworkers - http://crbug.com/31666

The architecture we are currently considering for talkilla uses sub workers only in the SocialAPI context (ie a context where we aren't guaranteed to always be showing web content). For the web-only solution, we will likely use a hidden iframe instead of the frame worker, so the subworkers we need in SocialAPI won't be subworkers in the web context.

Comment 4

[Mark Hammond [:markh] [:mhammond]]

Attachment: 896860-worker.patch

Changed to no longer depend on bug 891218, but otherwise almost identical.  Flagging Gavin for review as the patch is very simple and I'd like explicit approval for landing this in 25 (and Shane has explicitly requested we land it there.)

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 784681 [details] [diff] [review]
896860-worker.patch

r=me, assuming this really is super-needed and Talkilla people will be upset if we don't add it. It would be great if the rationale for adding it was elaborated on in this bug - I feel like comment 0 is a misrepresentation of the real motivation behind this change :)

Comment 6

[Shane Caraveo (:mixedpuppy)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #5)
> Comment on attachment 784681 [details] [diff] [review]
> 896860-worker.patch
> 
> r=me, assuming this really is super-needed and Talkilla people will be upset
> if we don't add it. It would be great if the rationale for adding it was
> elaborated on in this bug - I feel like comment 0 is a misrepresentation of
> the real motivation behind this change :)

It would cause significant delay (beyond a 6 week gap) in working with partners on the Talkilla side if the subworker is not available.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

At a higher level, what is the subworker used for, and why is that use case not addressed by other mechanisms already available to frameworkers?

Comment 8

[Mark Hammond [:markh] [:mhammond]]

oops - I didn't notice the conversation was ongoing, so landed it.

https://hg.mozilla.org/integration/fx-team/rev/526505030062

Comment 9

[Shane Caraveo (:mixedpuppy)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #7)
> At a higher level, what is the subworker used for, and why is that use case
> not addressed by other mechanisms already available to frameworkers?

Talkilla needs to support more than one backend.  Using a sub-worker keeps those isolated from each other and from the talkilla frameworker.  Having them be a worker with communication over a port provides a roadmap that can, in the future, be supported in web-only solutions as well as potentially migrating those backends into socialapi providers.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/526505030062