> > 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. > > this again assumes custom code running in the engine, rather than static > plugins
Actually, users can deploy their plugins somewhere outside Engine JBoss (HTML page to load plugin, JavaScript representing the plugin code, plus optional server-side plugin code), and have them referenced from within WebAdmin. Vojtech ----- Original Message ----- From: "Itamar Heim" <ih...@redhat.com> To: "Vojtech Szocs" <vsz...@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <eco...@redhat.com> Sent: Friday, July 27, 2012 2:42:08 PM Subject: Re: oVirt UI Plugins: Update on current progress On 07/27/2012 03:26 PM, Vojtech Szocs wrote: >> 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 a builtin servelet to provide the plugins is fine. > > 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. this again assumes custom code running in the engine, rather than static plugins > > Vojtech > > > ----- Original Message ----- > From: "Itamar Heim" <ih...@redhat.com> > To: "Vojtech Szocs" <vsz...@redhat.com> > Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" <eco...@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" <ih...@redhat.com> >> To: "Vojtech Szocs" <vsz...@redhat.com> >> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" >> <eco...@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" <ih...@redhat.com> >>> To: "Vojtech Szocs" <vsz...@redhat.com> >>> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" >>> <eco...@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" <ih...@redhat.com> >>>> To: "Vojtech Szocs" <vsz...@redhat.com> >>>> Cc: "engine-devel" <engine-devel@ovirt.org>, "Einav Cohen" >>>> <eco...@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). >>>> >>>> >>> >>> >> >> > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
