Community
Participate
Working Groups
We've talked about the need for a small/secure "shell service" API that a plugin could use to talk to its host page. Most of the shell services we speak of require the inner content plugin to know that it is in Orion and make specific notifications. I could imagine: - progress - prompting - notifications But even for the most loosely coupled example (remote editor), we first need a way to invoke save. I could imagine that we would want to pass either the raw content or a URL describing the content location. For the Pixlr plugin, I'm using an existing API that redirects to a URL on save. I added a saveHook.html that lives in the visual iframe and actually causes the save to happen. This is nice because we can then give the user a chance to validate the data before saving to the workspace. And the hosting page can ensure that the postMessage is from Orion itself (since we've redirected the plugin to the save hook). Even so, we should have some kind of API for the save notification to be posted from the inner iframe to the parent. For now I just rolled a custom notification. I could imagine us formalizing this...would it be a call to the plugin registry? or a new service called shell service? etc. To make progress on this issue I think we should reimplement the custom post message that I put in orion/content/saveHook.js and orion/content/content.js and have them using a middleman (shell service) with a more formal API. Then we can start adding a few more services.
Simon, I can own this bug but really need to discuss with you where we think this shell service API lives (do the notifications use the plugin registry?) etc....
I talked about this with Simon. When I wrote the bug, I was imagining some kind of "shell service" object that had a small set of API and hid the notion of the service registry and services from the plugin. The idea being, it's a security hole to let the plugin have the service registry and services. Simon is now talking about a plugin security model that let service providers, users, plugins, etc. define a security model. So instead of having a "shell service" with limited API, instead, we would assign permissions to plugins. Some plugins might be given access to the dialog service, or notification service, etc. Some might be given read permission on the file service, or read/write, etc. Given all this, I think this bug goes to Simon (you can rename it if you want) and I will focus on bugs like bug 371157.
An initial version is in place now that support sending objects back and forth as parameters. Note: objects are sent by reference so do not provide field access and all methods are converted to return a promise. I've tried to retain backwards compatibility with the existing plugin.js however if your plugin was using events you will need to update your plugin.js at least for now. -- There is still a lot of communication redundancy/duplication between plugin and pluginregistry that I need to clean up before marking fixed.
.
