[Engine-devel] oVirt UI Plugins: Update on current progress

Fri Jul 27 12:26:12 UTC 2012

> what do you mean by a servlet here?

I mean a dedicated servlet for rendering HTML page used to load the given plugin.

Such servlet (PluginSourcePageServlet in PoC patch) would assemble following information into a single HTML page that represents the plugin:
- plugin dependencies
- plugin configuration
- actual plugin code

On the other hand, if someone wants to develop a plugin completely on his own, he could take care of rendering plugin HTML page by himself (e.g. when someone wants to use GWT to build his plugins). We can discuss this on the upcoming meeting if necessary.

Vojtech

----- Original Message -----
From: "Itamar Heim" <iheim at redhat.com>
To: "Vojtech Szocs" <vszocs at redhat.com>
Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>
Sent: Monday, July 23, 2012 2:27:56 PM
Subject: Re: oVirt UI Plugins: Update on current progress

On 07/23/2012 03:26 PM, Vojtech Szocs wrote:
> I agree with your points. Deploying custom plugins on Engine JBoss, just for the purpose of sharing same origin, sounds a bit strange, and complicates things from package perspective.
>
> As for cross-origin iframe communication issues, there are several ways how to address them:
> - use CORS (Cross-Origin Resource Sharing) when serving plugin HTML pages from outside Engine JBoss
> - use HTML5 Window.postMessage (but its current implementation is typically limited to String-based communication)
>
> For now, let's stick to the standard way of developing UI plugins (using dedicated servlet for plugin HTML page).

what do you mean by a servlet here?

>
> Vojtech
>
>
> ----- Original Message -----
> From: "Itamar Heim" <iheim at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>
> Sent: Monday, July 23, 2012 12:16:04 PM
> Subject: Re: oVirt UI Plugins: Update on current progress
>
> On 07/23/2012 01:10 PM, Vojtech Szocs wrote:
>>> it is not supposed to be next to engine.jar, it is supposed to be
>>> somewhere else entirely, served to clients like any static content via a
>>> servelt.
>>
>> If the GWT UI plugin web application won't be deployed on Engine JBoss AS instance, we'll run into cross-origin iframe communication issues that we'll need to deal with.
>
> we'll need to solve these in any case for plugins which do have an
> existing external service.
>
>>
>> In other words, why prevent others to "keep away" from Engine JBoss AS instance? Why not let them deploy whatever they want next to engine.ear, given that they are doing this on their own responsibility?
>
> because once we tell people it is ok, it makes it our responsibility to
> make sure they don't break during upgrades for example (or worse, not
> fail the entire engine post an upgrade).
> I'm not saying these are not solvable, but i'd rather not try to handle
> them on the first cut of this framework.
>
>>
>>> that's not the scope we discussed so far.
>>> we discussed a 'static' plugin, which can use an external service or the
>>> REST API.
>>
>> This was actually option [1] as described in my email below.
>>
>>   From WebAdmin point-of-view, UI plugins are "static", as you wrote. UI plugins written in GWT, however, can include server-side logic on their own.
>>
>> Vojtech
>>
>>
>> ----- Original Message -----
>> From: "Itamar Heim" <iheim at redhat.com>
>> To: "Vojtech Szocs" <vszocs at redhat.com>
>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>
>> Sent: Monday, July 23, 2012 11:54:14 AM
>> Subject: Re: oVirt UI Plugins: Update on current progress
>>
>> On 07/23/2012 12:40 PM, Vojtech Szocs wrote:
>>>> this implies server side code running on the engine,
>>>
>>> Actually, yes and no :) let me explain:
>>>
>>> - UI plugins developed in GWT need some context (plugin web application deployed next to engine.ear) from which their code will be served
>>
>> it is not supposed to be next to engine.jar, it is supposed to be
>> somewhere else entirely, served to clients like any static content via a
>> servelt.
>>
>>> - UI plugin web applications can contain only static resources (HTML + generated JavaScript) -> answer is "NO"
>>> - UI plugin web applications can also contain server-side code (e.g. for GWT RPC) -> answer is "YES"
>>
>> that's not the scope we discussed so far.
>> we discussed a 'static' plugin, which can use an external service or the
>> REST API.
>>
>>>
>>>> which has additional implications on compatibility vs. ui plugins as discussed
>>>
>>> I don't think we need to worry about this :)
>>>
>>> If a GWT UI plugin web application needs to use Engine functionality, it can:
>>>
>>> - use REST API from within UI plugin (JavaScript) code [1]
>>> - use REST API from within its server-side (Java) code [2]
>>
>> again, if we want to discuss an approach to making ui plugins which need
>> server side cooperation not in a separate container of their own choice,
>> different server, etc. - we can, but lets separate the discussion on the
>> two.
>>
>>>
>>> [1] - will be supported by UI plugin infrastructure
>>> [2] - not supported by UI plugin infrastructure
>>>
>>> Vojtech
>>>
>>>
>>> ----- Original Message -----
>>> From: "Itamar Heim" <iheim at redhat.com>
>>> To: "Vojtech Szocs" <vszocs at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "Einav Cohen" <ecohen at redhat.com>
>>> Sent: Monday, July 23, 2012 9:10:07 AM
>>> Subject: Re: oVirt UI Plugins: Update on current progress
>>>
>>> On 07/20/2012 11:37 PM, Vojtech Szocs wrote:
>>>> Last but not least, writing plugins in Google Web Toolkit (GWT) should
>>>> be as easy as providing your own plugin source page. Just deploy your
>>>> GWT plugin application on JBoss AS (next to engine.ear), and point to
>>>> GWT plugin application host page.
>>>
>>> this implies server side code running on the engine, which has
>>> additional implications on compatibility vs. ui plugins as discussed so
>>> far which would be java script
>>> (I'm not against using GWT for them if the resulting java script can be
>>> packaged for use as a UI plugin, but sever side code i prefer to be
>>> isolated from engine until we'll define engine plugins).
>>>
>>>
>>
>>
>
>