--=_8c1ef5c2-c775-4be9-be4e-f09c4448d600
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi George,
I've been thinking about developing plugins with GWT. There are some important issues
that need to be addressed:
1. GWT bootstrap sequence requires permutation selector script (
<pluginApplication>.nocache.js ) to be invoked first. Selector script determines the
correct permutation ( <hashName>.cache.html ) and fetches it asynchronously from the
same location.
2. GWT bootstrap sequence is asynchronous in nature.
3. GWT RPC ( XMLHttpRequest ) is subject to Same Origin Policy [1]. This means that
pluginApplication 's server-side code should be deployed on oVirt JBoss AS instance
(next to engine.ear ).
Given these limitations, I'd say the process could be like this:
a) In pluginApplication 's EntryPoint , use GWT JSNI [2] to register the plugin using
native JavaScript code.
You don't need to use gwt-exporter here, since plugin registration and logic is
combined in one place.
Using plugin-to-GWT delegate pattern with gwt-exporter is actually more complicated than
going with plain JSNI.
For example:
package com.myplugin;
public class MyPluginApp implements com.google.gwt.core.client.EntryPoint {
public void void onModuleLoad() {
// Initialize plugin application, call registerPlugin() when ready
registerPlugin();
}
public static void tableContextMenu(com.google.gwt.core.client.JavaScriptObject
eventContext) {
// Consider using GWT overlay types [3] to easily work with JavaScriptObjects
}
private static native void registerPlugin() /*-{
// Register 'myPlugin' into pluginApi.plugins object
$wnd.pluginApi.plugins.myPlugin = myPlugin = {
tableContextMenu: function(eventContext) {
// Call Java static method to handle this event
@com.myplugin.MyPluginApp::tableContextMenu(Lcom/google/gwt/core/client/JavaScriptObject;)(eventContext);
}
};
// Call the ready() function right away
$wnd.pluginApi.lifecycle(myPlugin).ready();
}-*/;
}
b) Deploy the <pluginApplication>.war file on JBoss AS instance, e.g.
<JBOSS_HOME>/standalone/deployments .
This makes pluginApplication 's GWT RPC servlet(s) accessible from the same origin
(protocol, domain, port).
c) Modification of plugin lifecycle step #5:
Instead of embedding <pluginApplication>.nocache.js content into WebAdmin HTML page,
just embed the link to it, e.g.
http(s)://127.0.0.1:<port>/path/to/<pluginApplication>.nocache.js
d) Modification of plugin lifecycle step #6:
During WebAdmin startup, for each plugin that is supposed to be loaded remotely, create an
<iframe> that will fetch the plugin asynchronously.
The <iframe> is required in order for <pluginApplication>.nocache.js to appear
from different ( pluginApplication -specific ) domain than WebAdmin HTML page.
This way, fetching permutation ( <hashName>.cache.html ) files, which are relative
to <pluginApplication>.nocache.js , will work out-of-the-box.
George, please let me know what you think, and I will update UI Plugins wiki accordingly.
Vojtech
[1]
http://en.wikipedia.org/wiki/Same_origin_policy
[2]
https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasics...
[3]
https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasics...
----- Original Message -----
From: "George Costea" <George.Costea(a)netapp.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>, engine-devel(a)ovirt.org
Cc: "Dustin Schoenbrun" <Dustin.Schoenbrun(a)netapp.com>, "Ricky
Hopper" <Ricky.Hopper(a)netapp.com>, "Itamar Heim"
<iheim(a)redhat.com>
Sent: Monday, June 25, 2012 9:11:33 PM
Subject: RE: oVirt UI Plugins feature: Ready for review
Thanks Vojtech.
Since the plugins are embedded into the WebAdmin HTML page, that seems to simplify things;
no external web service is needed. This approach ties into the issue over the freedom to
decide which technology to use when developing a plugin. While I agree that jQuery is best
for simple dialogs, a wizard-driven workflow is easier to develop in GWT.
For example, if I want to step a user through the process of creating a new storage domain
I would like to provide a workflow to select a storage array, provide credentials, and
configure the details of the NFS export. This workflow could presumably have a GWT-RPC
mechanism that relies on some additional libraries on the backend (libraries that allow me
to communicate with the storage array). Using the GWT-Exporter, I could export the classes
that would display the workflow which would then get launched as my extension is selected.
You said that I would have my oVirt UI plugin depend on my compiled 'plugin support
application'. My compiled plugin support application would normally be a war file
containing my compiled GWT code and a web-inf folder containing my libraries. Is the
plugin depending on the war file? Is that what I specify?
-George
-----Original Message-----
From: Vojtech Szocs [mailto:vszocs@redhat.com]
Sent: Monday, June 25, 2012 1:12 PM
To: Costea, George; engine-devel(a)ovirt.org
Cc: Schoenbrun, Dustin; Hopper, Ricky; Itamar Heim
Subject: Re: oVirt UI Plugins feature: Ready for review
Hi George,
thanks for your feedback. Please find my answers below.
1) Are the plugins hosted by the same jboss server that hosts the engine? It would appear
the answer is yes and that no separate container is required for the plugins.
In short, yes.
Plugins, along with their configuration and 3rd party dependencies, are meant to be
embedded into final WebAdmin HTML page, see
[
http://www.ovirt.org/wiki/Features/UIPlugins#Plugin_lifecycle] step #5.
JBoss AS instance serves WebAdmin HTML page (WebadminDynamicHostingServlet), along with
providing GWT RPC and REST endpoints that delegate to Engine business logic through EJB
BackendLocal interface.
However, plugins are not 'hosted' in a typical sense -
WebadminDynamicHostingServlet reads and embeds all plugin data directly into final
WebAdmin HTML page.
<blockquote>
2) Does each plugin map to a unique extension within WebAdmin? Your example shows that I
can extend the VM table to have a "Show VM name and edit VM" context-sensitive
extension. This is named pluginApi.plugins.myPlugin. Can I safely assume that this is per
extension? I would have pluginApi.plugins.myPlugin2 for extending a storage domain?
Extension points are represented by application events, triggered by WebAdmin and consumed
by plugins. For example, 'tableContextMenu' event gets triggered when a table
context menu is about to be shown to the user, which gives plugins the ability to do
something custom with the context menu before it's shown.
</blockquote>
There can be multiple plugins handling the same event (extension point). You can have two
plugins, say 'pluginApi.plugins.One' and 'pluginApi.plugins.Two', each
providing 'tableContextMenu' function for handling the above mentioned event.
WebAdmin will invoke all plugins for the given event.
To answer your question, in order to handle X events (extension points), you don't
need to write X plugins. You can write one plugin that handles X events.
<blockquote>
3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to
display a dialog that fits my needs?
You can do anything you want in your plugin event handler function. Show a jQuery UI
dialog, make oVirt REST API request, call arbitrary remote server using cross-domain
technique like JSONP [1] or CORS [2], etc. Plugin authors are free to decide if they want
to rely on 3rd party JavaScript libraries, or if they want to write entire plugin code by
themselves.
</blockquote>
In my opinion, tools like jQuery are far more elegant for handling simple things such as
UI dialogs. But if you really want to use GWT for this purpose, I suggest following
approach:
a, develop a 'plugin support application' in GWT, which implements the necessary
dialog functionality b, export its main (e.g. dialog handling) classes for use in native
JavaScript through gwt-exporter [3] c, have your oVirt UI plugin depend on your compiled
'plugin support application' (this will cause your 'plugin support
application' to be called during WebAdmin startup) d, in your oVirt UI plugin, invoke
'plugin support application' functionality through exported classes (plugin ->
GWT delegate pattern)
<blockquote>
4) Is session info passed into the plugin so that I can invoke APIs into the engine? To
power on a VM for instance? Or to mount a new NFS storage domain?
Yes, this should be part of
[
http://www.ovirt.org/wiki/Features/UIPlugins#Global_API_functions] "Plugin utility
functions" (global API).
</blockquote>
Your plugin might access user session information in the following way:
pluginApi.util().userInfo().* (replace * with id(), name(), domain(), etc.)
As you pointed out, this could be used to authenticate oVirt REST API requests made from
your plugin code.
<blockquote>
BTW, the link to the original design notes on the wiki doesn't work.
This is strange, [
http://rhevmf.pad.engineering.redhat.com/68] has its visibility set to
"Public (Allow Internet guests)" ... Does anybody know why this doesn't
work?
</blockquote>
Vojtech
[1]
http://en.wikipedia.org/wiki/JSONP
[2]
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
[3]
http://code.google.com/p/gwt-exporter/
----- Original Message -----
From: "George Costea" <George.Costea(a)netapp.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>, engine-devel(a)ovirt.org
Cc: "Dustin Schoenbrun" <Dustin.Schoenbrun(a)netapp.com>, "Ricky
Hopper" <Ricky.Hopper(a)netapp.com>
Sent: Monday, June 25, 2012 3:09:43 PM
Subject: RE: oVirt UI Plugins feature: Ready for review
Hi Vojtech,
I have a few questions on this feature.
1) Are the plugins hosted by the same jboss server that hosts the engine? It would appear
the answer is yes and that no separate container is required for the plugins.
2) Does each plugin map to a unique extension within WebAdmin? Your example shows that I
can extend the VM table to have a "Show VM name and edit VM" context-sensitive
extension. This is named pluginApi.plugins.myPlugin. Can I safely assume that this is per
extension? I would have pluginApi.plugins.myPlugin2 for extending a storage domain?
3) Instead of launching a jQuery dialog, can I point to a compiled GWT html file to
display a dialog that fits my needs?
4) Is session info passed into the plugin so that I can invoke APIs into the engine? To
power on a VM for instance? Or to mount a new NFS storage domain?
BTW, the link to the original design notes on the wiki doesn't work.
Thanks,
George
-----Original Message-----
From: Vojtech Szocs [mailto:vszocs@redhat.com]
Sent: Thursday, June 21, 2012 11:03 AM
To: engine-devel(a)ovirt.org
Cc: Schoenbrun, Dustin; Costea, George; Hopper, Ricky
Subject: oVirt UI Plugins feature: Ready for review
Hi guys,
I wrote a wiki page describing UI Plugins, a feature planned for oVirt web administration
(WebAdmin) application:
http://www.ovirt.org/wiki/Features/UIPlugins
Feature design is finished and ready for review. Please feel free to add comments, ask
questions or reach me directly on #ovirt channel.
Cheers,
Vojtech
--=_8c1ef5c2-c775-4be9-be4e-f09c4448d600
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><style type=3D'text/css'>p { margin: 0;
}</style></head><body><=
div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'=
<font size=3D"4">Hi
George,<br><br>I've been thinking about developing plu=
gins with
GWT. There are some important issues that need to be addressed:<b=
r></font><ol><li><font size=3D"4">GWT bootstrap
sequence requires <em>permu=
tation selector script</em> (<font size=3D"3"><span
style=3D"font-family: l=
ucida
console,sans-serif;"><pluginApplication>.nocache.js</span></fon=
t>) to be invoked first.<br>Selector script determines the correct permutat=
ion (<font style=3D"font-family: lucida console,sans-serif;"
size=3D"3"><=
;hashName>.cache.html</font>) and fetches it asynchronously from the sam=
e location.<br><br></font></li><li><font
size=3D"4">GWT bootstrap sequence =
is asynchronous in nature.<br><br></font></li><li><font
size=3D"4">GWT RPC =
(<font style=3D"font-family: lucida console,sans-serif;"
size=3D"3">XMLHttp=
Request</font>) is subject to Same Origin Policy [1].<br>This means that
<s=
pan style=3D"font-style: italic;">pluginApplication</span>'s
server-side co=
de should be deployed on oVirt JBoss AS instance (next to <font style=3D"fo=
nt-family: lucida console,sans-serif;"
size=3D"3">engine.ear</font>).<br></=
font></li></ol><font size=3D"4"><br>Given these
limitations, I'd say the pr=
ocess could be like this:<br><br>a) In <span style=3D"font-style:
italic;">=
pluginApplication</span>'s <font style=3D"font-family: lucida
console,sans-=
serif;" size=3D"3">EntryPoint</font>, use GWT JSNI [2] to register
the plug=
in using native JavaScript code.<br><br> You don't
need to use =
<span style=3D"font-style: italic;">gwt-exporter</span> here, since
plugin =
registration and logic is combined in one place.<br> Using
plug=
in-to-GWT delegate pattern with <span style=3D"font-style:
italic;">gwt-exp=
orter</span> is actually more complicated than going with plain
JSNI.<br><b=
r> For example:<br><br><font
style=3D"font-family: lucida conso=
le,sans-serif;" size=3D"3"> package
com.myplugin;<br><br> =
public class MyPluginApp implements com.google.gwt.core.client.Entry=
Point {<br><br> public void void
onModuleLoad() {<=
br> // Initialize plugin
application, call=
registerPlugin() when ready<br>
registerP=
lugin();<br>
}<br><br> pu=
blic static void tableContextMenu(com.google.gwt.core.client.JavaScriptObje=
ct eventContext) {<br> //
Consider using G=
WT overlay types [3] to easily work with JavaScriptObjects<br>
=
}<br><br>
private static native void =
registerPlugin() /*-{<br> //
Register 'myP=
lugin' into pluginApi.plugins object<br>
$=
wnd.pluginApi.plugins.myPlugin =3D myPlugin =3D {<br>
&n=
bsp; tableContextMenu: function(eventContext)
{<br>&nbs=
p; // Call
Java static meth=
od to handle this event<br>
=
@com.myplugin.MyPluginApp::tableContextMenu(Lcom/google/gwt/core/cli=
ent/JavaScriptObject;)(eventContext);<br>
=
}<br>
};<br> &nbs=
p; // Call the ready() function right
away<br> &n=
bsp;
$wnd.pluginApi.lifecycle(myPlugin).ready();<br> &nb=
sp; }-*/;<br><br>
}</font><br><br>b) Deploy the <f=
ont style=3D"font-family: lucida console,sans-serif;"
size=3D"3"><plugin=
Application>.war</font> file on JBoss AS instance, e.g. <font
style=3D"f=
ont-family: lucida console,sans-serif;"
size=3D"3"><JBOSS_HOME>/stand=
alone/deployments</font>.<br><br> This makes
<span style=3D"fon=
t-style: italic;">pluginApplication</span>'s GWT RPC servlet(s)
accessible =
from the same origin (protocol, domain, port).<br><br>c) Modification of pl=
ugin lifecycle step #5:<br><br> Instead of embedding
<font styl=
e=3D"font-family: lucida console,sans-serif;"
size=3D"3"><pluginApplicat=
ion>.nocache.js</font> content into WebAdmin HTML page, just embed the l=
ink to it, e.g. <font style=3D"font-family: lucida console,sans-serif;" siz=
e=3D"3">http(s)://127.0.0.1:<port>/path/to/<pluginApplication>.=
nocache.js</font><br><br>d) Modification of plugin lifecycle step
#6:<br><b=
r> During WebAdmin startup, for each plugin that is supposed to=
be loaded remotely, create an <font size=3D"3"><span
style=3D"font-family:=
lucida console,sans-serif;"><iframe></span></font> that
will fetch t=
he plugin asynchronously.<br><br> The <font
style=3D"font-famil=
y: lucida console,sans-serif;"
size=3D"3"><iframe></font> is required=
in order for <font size=3D"3"><span style=3D"font-family: lucida
console,s=
ans-serif;"><pluginApplication>.nocache.js</span></font>
to appear fr=
om different (</font><font size=3D"4"><span
style=3D"font-style: italic;">p=
luginApplication</span>-specific</font><font size=3D"4">)
domain than WebAd=
min HTML page.<br><br> This way, fetching permutation
(<font st=
yle=3D"font-family: lucida console,sans-serif;"
size=3D"3"><hashName>=
.cache.html</font>) files, which are relative to <font
style=3D"font-family=
: lucida console,sans-serif;"
size=3D"3"><pluginApplication>.nocache.=
js</font>, will work out-of-the-box.<br><br><br>George, please let
me know =
what you think, and I will update UI Plugins wiki accordingly.<br><br>Vojte=
ch<br><br><br>[1]
http://en.wikipedia.org/wiki/Same_origin_policy<br>[2] ht=
tps://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsJSNI=
<br>[3]
https://developers.google.com/web-toolkit/doc/latest/DevGuideCoding=
BasicsOverlay<br><br></font><br><hr
id=3D"zwchr"><br>From: "George Costea" =
&lt;George.Costea(a)netapp.com&gt;<br>To: "Vojtech Szocs"
&lt;vszocs(a)redhat.c=
om>, engine-devel(a)ovirt.org<br>Cc: "Dustin Schoenbrun"
<Dustin.Schoen=
brun(a)netapp.com&gt;, "Ricky Hopper" &lt;Ricky.Hopper(a)netapp.com&gt;,
"Itama=
r Heim" &lt;iheim(a)redhat.com&gt;<br>Sent: Monday, June 25, 2012 9:11:33
PM<=
br>Subject: RE: oVirt UI Plugins feature: Ready for review<br><br>Thanks
Vo=
jtech.<br><br>Since the plugins are embedded into the WebAdmin HTML page, t=
hat seems to simplify things; no external web service is needed. This=
approach ties into the issue over the freedom to decide which technology t=
o use when developing a plugin. While I agree that jQuery is best for=
simple dialogs, a wizard-driven workflow is easier to develop in GWT. &nbs=
p;<br><br>For example, if I want to step a user through the process of crea=
ting a new storage domain I would like to provide a workflow to select a st=
orage array, provide credentials, and configure the details of the NFS expo=
rt. This workflow could presumably have a GWT-RPC mechanism that reli=
es on some additional libraries on the backend (libraries that allow me to =
communicate with the storage array). Using the GWT-Exporter, I could =
export the classes that would display the workflow which would then get lau=
nched as my extension is selected. You said that I would have my oVir=
t UI plugin depend on my compiled 'plugin support application'. My co=
mpiled plugin support application would normally be a war file containing m=
y compiled GWT code and a web-inf folder containing my libraries. Is =
the plugin depending on the war file? Is that what I
specify?<br><br>=
-George<br><br>-----Original Message-----<br>From: Vojtech Szocs
[mailto:vs=
zocs(a)redhat.com] <br>Sent: Monday, June 25, 2012 1:12 PM<br>To: Costea, Geo=
rge; engine-devel(a)ovirt.org<br>Cc: Schoenbrun, Dustin; Hopper, Ricky; Itama=
r Heim<br>Subject: Re: oVirt UI Plugins feature: Ready for
review<br><br>Hi=
George,<br><br>thanks for your feedback. Please find my answers
below.<br>=
<br><br><blockquote> 1) Are the plugins hosted by the same jboss server
tha=
t hosts the engine? It would appear the answer is yes and that no sep=
arate container is required for the plugins.<br><br>In short,
yes.</blockqu=
ote><br><br>Plugins, along with their configuration and 3rd party
dependenc=
ies, are meant to be embedded into final WebAdmin HTML page, see [
http://ww=
w.ovirt.org/wiki/Features/UIPlugins#Plugin_lifecycle] step #5. <br>JBoss AS=
instance serves WebAdmin HTML page (WebadminDynamicHostingServlet), along =
with providing GWT RPC and REST endpoints that delegate to Engine business =
logic through EJB BackendLocal interface.<br><br>However, plugins are not
'=
hosted' in a typical sense - WebadminDynamicHostingServlet reads and embeds=
all plugin data directly into final WebAdmin HTML
page.<br><br><br><blockq=
uote> 2) Does each plugin map to a unique extension within WebAdmin? =
Your example shows that I can extend the VM table to have a "Show VM name a=
nd edit VM" context-sensitive extension. This is named pluginApi.plug=
ins.myPlugin. Can I safely assume that this is per extension? I=
would have pluginApi.plugins.myPlugin2 for extending a storage domain?<br>=
<br>Extension points are represented by application events, triggered by We=
bAdmin and consumed by plugins. For example, 'tableContextMenu' event gets =
triggered when a table context menu is about to be shown to the user, which=
gives plugins the ability to do something custom with the context menu bef=
ore it's shown.</blockquote><br><br>There can be multiple plugins
handling =
the same event (extension point). You can have two plugins, say 'pluginApi.=
plugins.One' and 'pluginApi.plugins.Two', each providing
'tableContextMenu'=
function for handling the above mentioned event. WebAdmin will invoke all =
plugins for the given event.<br><br>To answer your question, in order to ha=
ndle X events (extension points), you don't need to write X plugins. You ca=
n write one plugin that handles X events.<br><br><br><blockquote>
3) Instea=
d of launching a jQuery dialog, can I point to a compiled GWT html file to =
display a dialog that fits my needs?<br><br>You can do anything you want in=
your plugin event handler function. Show a jQuery UI dialog, make oVirt RE=
ST API request, call arbitrary remote server using cross-domain technique l=
ike JSONP [1] or CORS [2], etc. Plugin authors are free to decide if they w=
ant to rely on 3rd party JavaScript libraries, or if they want to write ent=
ire plugin code by themselves.</blockquote><br><br>In my opinion, tools
lik=
e jQuery are far more elegant for handling simple things such as UI dialogs=
. But if you really want to use GWT for this purpose, I suggest following a=
pproach:<br><br>a, develop a 'plugin support application' in GWT,
which imp=
lements the necessary dialog functionality b, export its main (e.g. dialog =
handling) classes for use in native JavaScript through gwt-exporter [3] c, =
have your oVirt UI plugin depend on your compiled 'plugin support applicati=
on' (this will cause your 'plugin support application' to be called during =
WebAdmin startup) d, in your oVirt UI plugin, invoke 'plugin support applic=
ation' functionality through exported classes (plugin -> GWT delegate pa=
ttern)<br><br><br><blockquote> 4) Is session info passed into the
plugin so=
that I can invoke APIs into the engine? To power on a VM for instanc=
e? Or to mount a new NFS storage domain?<br><br>Yes, this should be
p=
art of [
http://www.ovirt.org/wiki/Features/UIPlugins#Global_API_functions] =
"Plugin utility functions" (global
API).</blockquote><br><br>Your plugin mi=
ght access user session information in the following way: pluginApi.util().=
userInfo().* (replace * with id(), name(), domain(), etc.)<br><br>As you po=
inted out, this could be used to authenticate oVirt REST API requests made =
from your plugin code.<br><br><br><blockquote> BTW, the link to
the origina=
l design notes on the wiki doesn't work.<br><br>This is strange,
[
http://rh=
evmf.pad.engineering.redhat.com/68] has its visibility set to "Public (Allo=
w Internet guests)" ... Does anybody know why this doesn't work?</blockquot=
e><br><br><br>Vojtech<br><br><br>[1]
http://en.wikipedia.org/wiki/JSONP<br>=
[2]
http://en.wikipedia.org/wiki/Cross-origin_resource_sharing<br>[3] http:=
//code.google.com/p/gwt-exporter/<br><br><br>----- Original Message
-----<b=
r>From: "George Costea" &lt;George.Costea(a)netapp.com&gt;<br>To:
"Vojtech Sz=
ocs" &lt;vszocs(a)redhat.com&gt;, engine-devel(a)ovirt.org<br>Cc:
"Dustin Schoe=
nbrun" &lt;Dustin.Schoenbrun(a)netapp.com&gt;, "Ricky Hopper"
<Ricky.Hoppe=
r(a)netapp.com&gt;<br>Sent: Monday, June 25, 2012 3:09:43 PM<br>Subject: RE:
=
oVirt UI Plugins feature: Ready for review<br><br>Hi
Vojtech,<br><br>I have=
a few questions on this feature.<br><br>1) Are the plugins hosted by the s=
ame jboss server that hosts the engine? It would appear the answer is=
yes and that no separate container is required for the plugins.<br>2) Does=
each plugin map to a unique extension within WebAdmin? Your example =
shows that I can extend the VM table to have a "Show VM name and edit VM" c=
ontext-sensitive extension. This is named pluginApi.plugins.myPlugin.=
Can I safely assume that this is per extension? I would have p=
luginApi.plugins.myPlugin2 for extending a storage domain?<br>3) Instead of=
launching a jQuery dialog, can I point to a compiled GWT html file to disp=
lay a dialog that fits my needs?<br>4) Is session info passed into the plug=
in so that I can invoke APIs into the engine? To power on a VM for in=
stance? Or to mount a new NFS storage domain?<br><br>BTW, the link
to=
the original design notes on the wiki doesn't
work.<br><br>Thanks,<br>Geor=
ge<br><br>-----Original Message-----<br>From: Vojtech Szocs
[mailto:vszocs@=
redhat.com]<br>Sent: Thursday, June 21, 2012 11:03 AM<br>To: engine-devel@o=
virt.org<br>Cc: Schoenbrun, Dustin; Costea, George; Hopper, Ricky<br>Subjec=
t: oVirt UI Plugins feature: Ready for review<br><br>Hi
guys,<br><br>I wrot=
e a wiki page describing UI Plugins, a feature planned for oVirt web admini=
stration (WebAdmin)
application:<br>http://www.ovirt.org/wiki/Features/UIPl=
ugins<br><br>Feature design is finished and ready for review. Please feel f=
ree to add comments, ask questions or reach me directly on #ovirt channel.<=
br><br>Cheers,<br>Vojtech<br></div></body></html>
--=_8c1ef5c2-c775-4be9-be4e-f09c4448d600--