Closed
Bug 636151
Opened 14 years ago
Closed 14 years ago
Message passing / receiving across chrome / content
Categories
(Add-on SDK Graveyard :: General, defect, P1)
Add-on SDK Graveyard
General
Tracking
(Not tracked)
RESOLVED
FIXED
Future
People
(Reporter: irakli, Unassigned)
Details
Current message passing mechanics are very simple, which is great because one can build sugared message handler on top as library, but in reality it's not easy at all as, there is no ways to share reusable bits of code that will will be executed in a worker scope. This is also proved by having so many proposals, but with no implementation that can be used alternatively. Also amount of alternative proposals makes it clear that current API is too low level for many tasks.
- By Daniel: http://paste.mootools.net/f1236748
- By Me (Irakli): https://github.com/Gozala/vats
- By Alex: https://bugzilla.mozilla.org/show_bug.cgi?id=635748
- By Joe: https://github.com/joewalker/csstools/blob/master/lib/surrogate.js
While there are lot's of different proposals with alternative message passing APIs I think there is much more value in adding extensibility that would allow building all of them on top of existing API.
Also there is bunch of functionality that is useful as in chrome so in content contexts (for example: https://github.com/mozilla/addon-sdk/blob/master/packages/api-utils/lib/type.js)
I propose to provide implementation of `require` in the `content` scripts that will not have an access to the `chrome` module and there for will be restricted to the modules that are independent of chrome. This way we will make sdk much more flexible in terms of providing alternative to built-in APIs that can be build on top of built-in ones, in contrasts to current state where alternative APIs have to be implemented almost from scratch.
Reporter | ||
Comment 1•14 years ago
|
||
Main arguments to for not exposing `require` to the content workers was to have push devs to put more functionality on the addon side. While this sounds pretty good on a paper it does not makes much sense in real life as devs will end up doing whatever makes more sense. Here are few examples:
1. If in my content I need to have util functions like following: https://github.com/mozilla/addon-sdk/blob/master/packages/api-utils/lib/type.js regardless of existing limitations I will have to get them there as having them on the addon side won't be helpful as this functions `isFunction`, `isObject` .. etc work only with types that can not be passed through the `postMessage` this is also true for all the DOM related functionality.
2. Most of the content scripts modify DOM of the page and in addition may call postMessages to the chrome to fetch a `data` from server or to `open \ close` tabs / windows regardless all of the processing is done on the add-on side as it's just easier as you can get responseXML which you can pass with a `postMessage` also true for the tabs & windows. So if you do need to process something you'll do it on add-on side anyway. Also if you don't do any processing then it means that only thing you end up doing on the add-on side is a `postMessage` pipe to the content script.
In all the cases listed, I personally faced or could have come up with there was no single case have `require` influenced design. Also contrary there were cases were I and some others on the mailing list ended up building custom pipes for exposing reusable functionality from add-on to the content scripts that just decreased performance.
Comment 2•14 years ago
|
||
I like the idea of exposing require() to content scripts. It is something I bumped into as well, when working on the Workspace jetpack port in bug 636723.
Won't it complicate things? I mean, if we allow require() in content scripts, then the module implementations won't be able to assume they run in the addon process.
How will this work in the e10s world?
Reporter | ||
Comment 5•14 years ago
|
||
Comment for bug triage: I think this is very important and not very hard to implement either. Also please note that this is not a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=635748
Reporter | ||
Comment 6•14 years ago
|
||
(In reply to comment #2)
> I like the idea of exposing require() to content scripts. It is something I
> bumped into as well, when working on the Workspace jetpack port in bug 636723.
>
> Won't it complicate things? I mean, if we allow require() in content scripts,
> then the module implementations won't be able to assume they run in the addon
> process.
Not sure I understood your comment, but there will be following categories of modules:
1. Modules written strictly for add-on context.
2. Modules written strictly for chrome context.
3. Modules written strictly for content context.
4. Common modules that can be loaded in either of this contexts.
If modules will be organized in structure representing this categories I don't expect any confusion on complexity.
Also please not that for non-e10s version (1.0) 1st and 2nd is a same category.
Reporter | ||
Comment 7•14 years ago
|
||
(In reply to comment #4)
> How will this work in the e10s world?
Not sure I understand this question, do you mean implementation-vise ?
Comment 8•14 years ago
|
||
that's also interrelated to my current problem with L10n. Any worker that has no access to API has to receive it's l10n strings via message passing which is not a solution we can handle on a long run.
Updated•14 years ago
|
OS: Mac OS X → All
Priority: -- → P1
Hardware: x86 → All
Target Milestone: --- → 1.0b5
Reporter | ||
Comment 9•14 years ago
|
||
Just commenting to document my observation:
After talking to people and looking at things they are doing with page-mods it's clear that they need more modularity. Most of a times they create their own message pipes to react on events or to make requests to the server and then do things in the dom. Forcing them in building such pipes does not really has any positive impact on performance or security, actually it's more likely that they will build something less optimized / secure then if that will be baked inn in SDK or if it's distributed as 3rd party library that is well tested and used.
Updated•14 years ago
|
Target Milestone: 1.0b5 → Future
Reporter | ||
Comment 10•14 years ago
|
||
Closing this bug as we implemented port.on / emit to address this. We can implement something better in a future, but I don't think having this bug will be relevant to that work anyway!
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•