Orion/Visual Plugin Strategy
This page describes our current support for "visual plugins" in Orion and discusses where we need to go.
Browser as an IDE
For those coming to Orion from desktop IDE's, and in particular Eclipse, a common question is "can I extend Orion's UI similarly to what I do in Eclipse today?" The answer is that the extension model is similar in many ways, but the key conceptual difference to be understood is that the browser is the IDE.
Developers work with many tools in the context of doing their work: editors, bug tracking systems, source control, test tools, image and graphics tools, etc. Orion is not a visual container for all your IDE tooling. We consider the browser to be the visual container and in Orion we focus on identifying the tasks that are integral to web development and providing pages that support these tasks. Orion's plugin architecture and extension model allow developers to contribute new behavior to existing Orion pages and to link to pages from other sites.
Orion UI extensions vs. Eclipse extensions
Many of the UI extension points in Orion should look familiar to the Eclipse developer.
Views and Editors
Unlike Eclipse, Orion doesn't have extension points like "view" or "editor" wherein a plugin can open a visual rectangle inside Orion and display some content. Since the browser is the IDE, we expect a contribution of a view or new kind of editor to be made by building a page. That page is linked to Orion via our various command or link extension points. Perhaps some day we will support "show view" and open a box on our page, but this is not where we wanted to start. Given our bias toward the Eclipse IDE, we wanted to first push the envelope on task-oriented pages managed via browser tabs (and all the interesting browser UI extensions for tabs) rather than building a plugin model that creates an IDE mashup.
Working with the editor should feel quite familiar to someone who has extended the eclipse editor. We have editor extension points that are quite similar to those in Eclipse, such as content assist, editor line annotations, custom outliners, etc. The API's are structured differently given we are communicating across an iframe to a plugin hosted on another site, but the spirit is quite similar.
Contributing commands to places like the navigator or editor is conceptually similar to what you would do in eclipse. What's different is that we currently avoid any specification of "well known UI contribution locations" such as toolbar groups, known menus, etc. It may come to this, but today we focus on semantic elements in a page anatomy. Plugins can contributor editor and navigator commands, or primary navigation links, but where these are represented is handled internally. INSIDE Orion, our pages are still doing some grouping/separation/ordering of command contributions, but at least for now, plugin contributions of the same are more limited, and our pages figure out where contributed commands belong on the page. This difference gives us the flexibility to evolve the UI, and we hope provide more flexibility to those who might wish to completely reskin Orion.
Another point is that some contributions that might be considered command contributions in Eclipse are more appropriately described as links in Orion. If you want to link to content related to a particular Orion task, or an individual resource, you shouldn't need to write a command to do so. Instead, you can supply links in various ways, so that existing Orion content (editor content, page text, command menus) include links to your contribution.
Don't Call Us, We'll Call You
Due to the distributed nature of Orion plugins, most of our UI contributions are "don't call us, we'll call you." For example, a plug-in can contribute a command (with keybinding, icon, tooltip), or register a navigation link that links back to the plugin. But Orion hooks it up and calls the plugin when it's time to do something. (Today) there is not much interaction where the plugin decides it's time to talk to Orion.
It's clear that we have some missing pieces. Mailing list discussions such as  and  have shown the need for a tighter level of visual integration than we have today. It's all well and good to link from Orion to a plugin's custom view and editor, but plugin developers want these pages to look like Orion pages. This means:
- Orion banner, footer, branding
- Access to Orion toolbar
- Access to status and progress messages
- Access to user preferences
- Access to the workspace/file service
Delegating Content into Orion
One way to do visual integration is to have plugin content come from outside Orion into an Orion page template that hosts an iframe containing the plug-ins' content. This would be the first case of a UI extension where instead of "don't call us we'll call you" a plugin starts talking to Orion services, such as "open this dialog" or "here's my status message." The services needed to do so are there already, but we haven't packaged up the minimal code needed on the plugin side to call them, and work through any security scenarios.
If we defined a new extension point (imagine "orion.page.content") in which plugins could run visually inside an iframe and talk to "shell services" is this enough? In effect it is orion hosting the page and delegating the page content to the plugin.
And if we can host one big content rectangle, why not host more than one and let the user mix and match the boxes?
Consuming Orion Chrome in another Page
Another approach might be for the integrator to add support to an existing page hosted at another site which is able to consume the Orion chrome and the common code that scans links, builds dimension menus, related pages, etc. This is not just a matter of "look and feel" for the plugin, but a loose level of integration in which the page can describe its content to some Orion code and that code builds links and relationships to other parts of Orion.
This loose coupling allows an existing web app that links into Orion via a plugin to look a little more integrated, as well as add more links back into Orion. So rather than thinking about an Orion hosted page that delegates the page content to some plugin, we instead have a "plugin's" page which is consuming Orion's chrome. The only thing in this example that is a plugin is the link that is shown in Orion. That link leads to an independent page which is running enough Orion code to link back in interesting ways.
Exposing Service APIs
Either way of doing it, we need for plugins to initiate calls to Orion services.
In the "delegated content" scenario, the plugin's content iframe is calling the shell services of Orion. We need to work through the security scenarios here. For example, it seems appropriate for a visual plugin to have access to command definition and rendering inside its content iframe. But it seems inappropriate (?) for a link scanner extension to grab the command framework directly and insert additional URL or key bindings into the hosting page rather than using the extension points to do so.
In the "consumable chrome" scenario, the plugin's page needs some minimally packaged set of shell services wherein it can describe itself to the chrome and get common services, look and feel. Given that it's the one hosting the page, the security risks to Orion are not the same. It is merely consuming some subset of Orion's services that it determined was useful for its implementation. (Not unlike consuming the editor or anything else we think of as a component.)