Re: [orion-dev] Fw: A complex plugin use case (number 1)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]

Re: [orion-dev] Fw: A complex plugin use case (number 1)

From: Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
Date: Thu, 8 Mar 2012 12:48:00 -0800
Delivered-to: orion-dev@xxxxxxxxxxx
List-archive: <https://dev.eclipse.org/mailman/private/orion-dev>
List-help: <mailto:orion-dev-request@eclipse.org?subject=help>
List-subscribe: <https://dev.eclipse.org/mailman/listinfo/orion-dev>, <mailto:orion-dev-request@eclipse.org?subject=subscribe>
List-unsubscribe: <https://dev.eclipse.org/mailman/options/orion-dev>, <mailto:orion-dev-request@eclipse.org?subject=unsubscribe>

thanks, Andrew.
Yes, I discussed this a bit with Simon. We know it's a very contrived example, and is making a lot of assumptions.
We are totally relying on the fact that the orion.eclipse.org data is marked "world readable" so that pixlr can access that URL without any authentication, etc. If the user had installed another file service (WebDAV, etc.) that required authentication, it wouldn't work either. We also have the reverse case when we need to retrieve the data (ie, getting the saved file from pixlr, or "apply patch from URL")....there may be authentication required for us to grab data from somewhere else. For the first case (getting the Orion data), we've talked about having the user be able to mark which files/folders in the workspace are readable, but as you point out, that doesn't solve the firewall issue. For the firewall case and localhost case, it obviously gets more involved....some kind of proxy server that can read the Orion data and make some of it available publically, or else an authentication handshake, etc.

Every time we talk about our cross site workflows we talk about the complications: authentication contexts, the workspace data being protected, the file system potentially living on a different server than Orion, etc. etc. The example doesn't handle any of this yet. But I'm using it to push on the scenario and identify the specific problems. I also think if we can get the "remote editor" example out there, people will try it and surface combinations of issues we haven't imagined yet.

susan

Andrew Eisenberg ---03/08/2012 10:33:48 AM---Hi Susan, I didn't want to derail the call, so I didn't mention this earlier. I

From: Andrew Eisenberg <andrew@xxxxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 03/08/2012 10:33 AM
Subject: Re: [orion-dev] Fw: A complex plugin use case (number 1)
Sent by: orion-dev-bounces@xxxxxxxxxxx

Hi Susan,

I didn't want to derail the call, so I didn't mention this earlier. I tried your pixlr plugin. As a concept, the visual plugin looks nice, and opens up some big possibilities.

However, the pixlr plugin itself could not load the image I passed to it. I'm guessing this is because I am running Orion locally and the file:/ url for the image is being sent to pixlr on the remote server, which cannot be accessed.

This kind of problem will likely happen if you are behind a firewall and it shows a bit of a limitation on how information can be shared between the orion instance and the plugin.

I'm not sure of a good solution for this, but I wanted to let you know about the problem I had.

On Tue, Mar 6, 2012 at 5:52 PM, Susan Franklin McCourt <susan_franklin@xxxxxxxxxx> wrote:

hi, all. Sorry for the length of this, but I wanted to give a status update on what's happening with respect to visual plugins.
I've been doing some hacking to further explore the visual plugin idea, and it's definitely exposing issues/questions. I've released enough code that I think jjb and Kris could potentially hack around with it and provide feedback. Here are some links, things to look at.

The wiki page I mentioned before [1] talks about the general issue and the multiple ways we could approach the issue of having remote content that looks like Orion and links to other parts of Orion in interesting ways (via shared navigation, related pages, etc.) The idea is "who's in charge?" The content or Orion?
- if Orion is in charge, then we can build an Orion host page that delegates the content to some plugin/other site.
- if the content is in charge, it could consume some Orion code that can inject the shared page elements, to make itself look more like Orion and link back to Orion.

I think the former approach is especially useful when you are trying to integrate an existing web app that you can't change, such as an online editor. The latter approach may make more sense when the content is more knowledgeable about Orion, desiring a richer integration with the Orion chrome.

We decided to start some early experiments in this bug [2]. Please cc: on the bug if you are interested in the topic. The bug starts with the "Orion is in charge" scenario. This is a little more expedient for early experiments. If orion is in charge, then the hosting page (

orion.eclipse.org/content/content.html

) already has access to the orion extension registry, etc., and can call the existing code that creates the common page elements. This immediately lets us build a shared header, related links, search scoping, etc. Long run, I think we'll support both scenarios, but I'm hoping that what we're learning about how the content and common page code communicate is applicable for both scenarios. It will be a matter of plumbing and packaging up the functionality, "who calls who," etc.

All that said, I released some very early support of an "orion.page.content" service extension that delegates the page content to an iframe. My initial example for this is trying to embed the pixlr image editor. [3] To try it out, you can install the pixlr plugin on github [4] and then you should be able to use the navigator "open with" to open either pixlr or pixlr express.

The integration of the plugin is very coarse (ie...note the menu bar within the content area). But what I find interesting is that this approach lets a third party (my git hub plugin) integrate Orion with an existing web API without having to modify either. In the past we either download a js library from the web app we like, or put the plugin on their site, etc. The elusive "how do you save to the workspace" issue is still the challenge, but this work is already helping us to think about the problem in terms of small chunks of functionality that might be a win vs. big chunks like "I need access to the entire workspace." [5] I think that in the long run, the pixlr plugin could prove to be an example of a specific subset of delegated content, the "delegated editor."

Hopefully Kris can try integrating the gcli page using this approach and it should illuminate more things we need.

jjb, I'm still digesting your very thoughtful comments on this thread regarding task level pages, higher level workflows, etc. I'm not attempting to address that issue yet, but hopefully there is still something you can play with in this support. Feedback is welcome in the various bugs noted below, or here if you aren't sure where to start.

thanks,
susan

[1]

http://wiki.eclipse.org/Orion/Visual_Plugin_Strategy

[2]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=372914

[3]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=362067

[4]

http://sfmccourt.github.com/plugins/pixlr/pixlrPlugin.html

[5]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=373443

Susan Franklin McCourt---02/24/2012 10:22:34 AM---As part of our documentation effort this week, I wrote a *very quick* description of our strategy th

From:

Susan Franklin McCourt/Beaverton/IBM@IBMUS

To:

orion-dev@xxxxxxxxxxx

Date:

02/24/2012 10:22 AM

Subject:

[orion-dev] Fw: A complex plugin use case (number 1)

Sent by: orion-dev-bounces@xxxxxxxxxxx

As part of our documentation effort this week, I wrote a *very quick* description of our strategy thus far and why we've started out how we have. Apologies if this is all stating the obvious, but I thought it might help give context to our desire to be very conservative as a starting point.

http://wiki.eclipse.org/Orion/Visual_Plugin_Strategy

susan

----- Forwarded by Susan Franklin McCourt/Beaverton/IBM on 02/24/2012 10:19 AM -----

From:

Susan Franklin McCourt/Beaverton/IBM

To:

Orion developer discussions <

orion-dev@xxxxxxxxxxx

Cc:

Orion developer discussions <

orion-dev@xxxxxxxxxxx

orion-dev-bounces@xxxxxxxxxxx

Date:

02/24/2012 08:22 AM

Subject:

Re: [orion-dev] A complex plugin use case (number 1)

yes, I meant...next week or so.
When John described his use case, it struck me as classic "20 things" scenario from e4. He needs progress, status, toolbar access, etc. But otherwise would like to live in his own private iframe for content. We've been able to get by so far without "shell sharing" but we definitely need a story. The discussion just happened to come up during the RCx cycle when we are trying to lock things down...

susan

Mike Wilson ---02/24/2012 06:57:38 AM---> Something to discuss after 0.4 is declared?.... Sure. As long as you mean _as_soon_as_ 0.4 is decl

From:

Mike Wilson <

Mike_Wilson@xxxxxxxxxx

To:

Orion developer discussions <

orion-dev@xxxxxxxxxxx

Date:

02/24/2012 06:57 AM

Subject:

Re: [orion-dev] A complex plugin use case (number 1)

Sent by:

orion-dev-bounces@xxxxxxxxxxx

Something to discuss after 0.4 is declared?....
Sure. As long as you mean _as_soon_as_ 0.4 is declared. This is a *very* important discussion; i.e. we're not going to be able to declare a 1.0 without knowing what our story will be here.

My take: Up till now, we've been living with the limitations because of the nice security and separation-of-concerns characteristics, and because we wanted to see how far we could push this style. I don't think we ever believed that this would be good enough to handle all use cases though.

McQ.

Susan Franklin McCourt ---2012/02/23 23:06:20---I think saying we don't visual plugins is a strong statement.

From:	Susan Franklin McCourt <susan_franklin@xxxxxxxxxx>
To:	Orion developer discussions <orion-dev@xxxxxxxxxxx>
Cc:	Orion developer discussions <orion-dev@xxxxxxxxxxx>, orion-dev-bounces@xxxxxxxxxxx
Date:	2012/02/23 23:06
Subject:	Re: [orion-dev] A complex plugin use case (number 1)

I think saying we don't visual plugins is a strong statement.
We don't want a mashup architecture (plugins are rectangle boxes inside Orion).
The use case you described previously (you want the whole content area, you want the common header/footer, status area, etc.) fits in with our original vision of "eclipse application services", "shell sharing" etc. but we've never had a concrete use case to work through.

I realize I never answered your response to my questions...we had just entered RC1 and it's been a very busy time.
My take is that if both you and Kris and running into this, it's something to talk about.
The "content is an iframe, offer some shell sharing services" is a middle ground that is more palatable than the mashup/visual plugin idea.

Something to discuss after 0.4 is declared?....

susan

John J Barton ---02/23/2012 05:41:33 PM---This description sounds a lot like my Orion plugin player project:

https://github.com/johnjbarton/

From:

John J Barton <

johnjbarton@xxxxxxxxxxxxxxx

To:

Orion developer discussions <

orion-dev@xxxxxxxxxxx

Date:

02/23/2012 05:41 PM

Subject:

Re: [orion-dev] A complex plugin use case (number 1)

Sent by:

orion-dev-bounces@xxxxxxxxxxx

This description sounds a lot like my Orion plugin player project:

https://github.com/johnjbarton/orion.pluginPlayer

I abandon it for two reasons, 1) Orion team does not want visual plugins (see my post here with that title) 2) Orion does not (currently?) allow plugins to be extensible. I personally think the Orion architecture would be clearer and more powerful if the variable UI content were implemented as visual plugins. This would allow plugin author to achieve the goals that both Kris and I desire, a plugin that acts like it is part of Orion. Equally, parts of Orion can be reused more completely. For example, the current embedded editor is not very much like the orion editor page, reducing its usefulness as a component in a non-visual Orion plugin. I want to create a 'log' page plugin for Orion that would access the console and lots of other tracing info. In that log I want to directly embed editors. With the embedded editor I use now the user experience will be "oh this looks like an Orion editor but it's not the same one I use in my other window". jjb On Thu, Feb 23, 2012 at 4:23 PM, Kris De Volder <

kdvolder@xxxxxxxxxx

> wrote: > Following up on the call from this morning where it was mentioned I'm having some problems packaging up gcli stuff to contribute back, as well as separating the bits that are of general utility in such a way that external plugins can contribute the commands we need to support cloudfoundry and node js. > > I'll try to present a use case. > > Use case: package as a plugin the following functionality: > - contribute a link at the top of the page to open 'my page' > - implement this page so it looks like an orion page > - headers and footers etc. > - body of page contains contributed content > - contributed content displays gcli interface with commands like 'pwd', 'cd' and 'ls'. > > Needs: > - add a link to all pages (easy with 'pageLinks' service) > - able to generate header and footers with all the trimmings (bread crumb, search box, tool bar, etc.). > - access to the fileService to implement the main functionality of the page. > > I implemented something that has the right 'look' and works. But it is done mostly by using code like the navigator and git ui as copy pasting example. > > Problem 1: > > The first problem I hit when trying to package this as a plugin is how do I handle all the dependencies on orion modules loaded by requirejs if we are not on the same server (relative urls are all broken). > > I managed to get something working here only by hard-coding the paths to stuff on the server in requirejs configuration in the plugin page. That's really no good, since it assumes orion server runs in only exactly one place. > > Questions: > > Is there a better way than hard coding paths to orion requirejs modules into the plugin that uses them? > > Problem 2: > > After 'fixing' problem I hit a second problem. Although all requirejs modules got loaded... they were having trouble accessing server side rest APIs (cross domain xhr requests I think?). > > At this point I gave up and started packaging my stuff as an eclipse plugin instead. This was much easier and I was able to achieve a very clean separation, no orion code was modified at all. > > Kris > > PS: There's a part 2 to this story (how do I make my contributed stuff extensible itself in the right way. But I'll hold that for later). > > > > > _______________________________________________ > orion-dev mailing list >