Re: [orion-dev] Life as a plugin is pretty hard

[Simon Kaegi <Simon_Kaegi@xxxxxxxxxx>]

Thanks Rafael,

First you are quite correct that the treatment of plugins is harsh and indeed this is an architectural characteristic. Plugins are (currently) not trusted, sandboxed, invisible, and have an externally managed life-cycle. This was done for pragmatic reasons more than anything as we did not have the time to do a decent job of managing plugin permissions and we wanted to ensure installation of a plugin did not result in misuse of user data.

Plugin permissions was not something I personally am pushing for in 2.0 however if you have some use-cases where something along the lines of a trusted plugin makes sense I'm interested and think we can start doing something now (especially if you can help). The general idea I had in mind was that a plugin's metadata could include a "permissions" header that listed what privileges it required and then at installation time a user would be asked. If all permissions were granted the plugin would be "enabled" and upon activation the plugin could call getServices etc. to interact with the hosting page in a constrained manner.

To make this happen the plugin provider side would need augmentation around activation and service retrieval but this seems very doable. I wouldn't want to move too quickly on permissions but would be game for choosing a simple case to learn more. Bugzilla away...
-Simon

Rafael Chaves ---11/06/2012 11:58:50 AM---Hi all, As some of you know, I am building a specialized PaaS service and am using

From:	Rafael Chaves <rafael@xxxxxxxxxxxx>
To:	orion-dev@xxxxxxxxxxx,
Date:	11/06/2012 11:58 AM
Subject:	[orion-dev] Life as a plugin is pretty hard
Sent by:	orion-dev-bounces@xxxxxxxxxxx

---

Hi all,

As some of you know, I am building a specialized PaaS service and am using Orion as the development enviroment for the service. I am really happy to be able to build on Orion, building a professional web-based IDE on my own would have been impossible. So I am really thankful for your work on Orion.

One thing that sucks right now though is how the current design is limiting for plugins. If all you want to do is to plug into an existing page (for instance, to contribute an action), you are out of luck, because a plugin can't interact with the user, or present a result, or report progress, or access the project contents, or tap into other client services. 

Unless you provide your own page. Then, it seems, you can do much of what the built-in Orion plugins can do. However, that is not solving the problem, that is just a workaround. Unless the plugin provider really wants to offer a completely new UI to their users, such as the console, hosting and git services do. But the majority of plugins will have no need for such (nor do users would want that).

Here is the question then: what is the direction going forward? Is there intent in making plugins more like 1st class citizens, allowing for much richer integration than possible today? Is there a technical limitation (security) that makes that impossible? Or maybe, if it is not impossible, is this something the team deems important and is looking into overcoming at some point, like some sort of model of trusted plugins? 

As it stands now, I have been gathering a laundry list of weird quirks in my service which I don't think can be addressed without a significant change in Orion itself and how plugins work. I don't believe this is just a problem with some specific extension point, that can be addressed with a simple fix, it seems really an architectural characteristic, which makes it more of a strategic liability, and that is why I chose to ask here on orion-dev instead of on the newsgroup or on a bug report.

I'd be more than happy to help and test/evaluate any mechanisms the team comes up with and wants feedback on.

Thanks, and congrats on your first release! 

Rafael_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev