3:37 p.m.
--=_156c716f-6003-47a3-bcaa-20301ab51501
Content-Type: multipart/alternative;
boundary="=_1a8d4419-a4c3-4d94-96e2-c9d519481224"
--=_1a8d4419-a4c3-4d94-96e2-c9d519481224
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi guys,
I've spent some time working on UI Plugins proof-of-concept (PoC) implement=
ation, and thought I'd share my results with you. I've attached a patch tha=
t reflects the current progress.
The actual PoC implementation takes some inspiration from oVirt UI Plugins =
wiki page, and simplifies/streamlines/improves its main concepts. The goal =
is to have simple-to-use, yet flexible and robust plugin infrastructure. Ma=
jor changes to the original design are outlined below.
Each UI plugin runs within the context of an iframe, and therefore requires=
a plugin source page that executes the actual plugin code.
=E2=80=A2 iframe is essentially the sandbox for each plugin. We can dis=
able plugins by detaching their iframe elements from the main document duri=
ng WebAdmin runtime. This also allows us to implement features such as plug=
in safe mode (no plugins loaded on WebAdmin startup).
=E2=80=A2 Plugin source pages and WebAdmin host page share the same ori=
gin (protocol, domain, port), with plugin source pages being served through=
EngineManager application server (JBoss AS). This is to avoid cross-domain=
window/iframe communication issues, when the actual plugin code running in=
an iframe tries to register itself into WebAdmin main document's pluginApi=
object.
=E2=80=A2 There's a servlet designed to render plugin source page for a=
ll plugins ( PluginSourcePageServlet ). For the given plugin, it detects it=
s dependencies (3rd party JavaScript libraries) and configuration object (J=
SON data), reads the actual plugin code, and assembles everything into the =
resulting HTML page (to be evaluated by the plugin iframe).
=E2=80=A2 iframe isolates plugin dependencies (3rd party JavaScript lib=
raries) from other plugins and the main WebAdmin document. In practice, thi=
s means that plugin A can use jQuery 1.7 and plugin B can use jQuery 1.6 wi=
thout the fear of any clashes.
=E2=80=A2 Last but not least, writing plugins in Google Web Toolkit (GW=
T) 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.
The current PoC declares a simple plugin that gets loaded using hard-coded =
values in PluginSourcePageServlet . Actual plugin code registers the plugin=
into global pluginApi.plugins object, with one sample event handler functi=
on ( ActionButtonClick ). Just after that, the plugin reports in as ready b=
y calling pluginApi.ready function. This essentially puts the plugin into u=
se within WebAdmin.
To simulate extension point (application event to be consumed by plugins), =
when the user clicks "New server" button on "Virtual Machines" main
tab, Ac=
tionButtonClickEvent gets fired through WebAdmin event bus. PluginEventHand=
ler receives this event and invokes ActionButtonClick event handler functio=
n on all plugins.
(Note: for passing context objects from WebAdmin to plugin event handler fu=
nctions, I'm planning to experiment with gwt-exporter project [1]. This wou=
ld greatly simplify the way how WebAdmin exposes context-specific plugin AP=
I to event handler functions.)
As for the next step, I suggest to have some meeting (conference) to discus=
s the PoC in detail, and outline tasks for the near future. Also, please le=
t me know what you think of the PoC so far.
Cheers,
Vojtech
[1] http://code.google.com/p/gwt-exporter/
--=_1a8d4419-a4c3-4d94-96e2-c9d519481224
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'=
Hi guys,<br><br>I've spent some time working on UI
Plugins proof-of-concep=
t (PoC) implementation, and thought I'd share my
results with you. I've att=
ached a patch that reflects the current progress. <br><br>The actual PoC im=
plementation takes some inspiration from oVirt UI Plugins wiki page, and si=
mplifies/streamlines/improves its main concepts. The goal is to have simple=
-to-use, yet flexible and robust plugin infrastructure. Major changes to th=
e original design are outlined below.<br><br><strong>Each UI plugin runs
wi=
thin the context of an iframe, and therefore requires a </strong><span styl=
e=3D"font-style: italic; font-weight: bold;">plugin source
page</span><span=
style=3D"font-weight: bold;"> that executes the actual plugin
code.</span>=
<br><ul><li>iframe is essentially the sandbox for each plugin. We can
disab=
le plugins by detaching their iframe elements from the main document during=
WebAdmin runtime. This also allows us to implement features such as <em>pl=
ugin safe mode</em> (no plugins loaded on WebAdmin
startup).</li><li>Plugin=
source pages and WebAdmin host page share the same origin (protocol, domai=
n, port), with plugin source pages being served through EngineManager appli=
cation server (JBoss AS). This is to avoid cross-domain window/iframe commu=
nication issues, when the actual plugin code running in an iframe tries to =
register itself into WebAdmin main document's <span style=3D"font-style: it=
alic;">pluginApi</span> object.</li><li>There's a servlet
designed to rende=
r plugin source page for all plugins (<span style=3D"font-style:
italic;">P=
luginSourcePageServlet</span>). For the given plugin, it detects its depend=
encies (3rd party JavaScript libraries) and configuration object (JSON data=
), reads the actual plugin code, and assembles everything into the resultin=
g HTML page (to be evaluated by the plugin iframe).</li><li>iframe isolates=
plugin dependencies (3rd party JavaScript libraries) from other plugins an=
d the main WebAdmin document. In practice, this means that plugin A can use=
jQuery 1.7 and plugin B can use jQuery 1.6 without the fear of any clashes=
.</li><li>Last but not least, writing plugins in Google Web Toolkit (GWT) s=
hould be as easy as providing your own plugin source page. Just deploy your=
GWT plugin application on JBoss AS (next to <span style=3D"font-style: ita=
lic;">engine.ear</span>), and point to GWT plugin application host
page.<br=
</li></ul><p>The current PoC declares a simple
plugin that gets loaded usi=
ng hard-coded values in <span
style=3D"font-style: italic;">PluginSourcePag=
eServlet</span>. Actual plugin code registers the plugin into global <span =
style=3D"font-style: italic;">pluginApi.plugins</span> object, with one
sam=
ple event handler function (<span style=3D"font-style:
italic;">ActionButto=
nClick</span>). Just after that, the plugin reports in as ready by calling =
<span style=3D"font-style: italic;">pluginApi.ready</span> function.
This e=
ssentially puts the plugin into use within
WebAdmin.<br></p><p><br></p>To s=
imulate extension point (application event to be consumed by plugins), when=
the user clicks "New server" button on "Virtual Machines" main tab,
<span =
style=3D"font-style: italic;">ActionButtonClickEvent</span> gets fired
thro=
ugh WebAdmin event bus. <span style=3D"font-style:
italic;">PluginEventHand=
ler</span> receives this event and invokes <span style=3D"font-style:
itali=
c;">ActionButtonClick</span> event handler function on all
plugins.<br><p><=
br></p><p>(Note: for passing context objects from WebAdmin to plugin event
=
handler functions, I'm planning to experiment with gwt-exporter project [1]=
. This would greatly simplify the way how WebAdmin exposes context-specific=
plugin API to event handler functions.)</p><p><br></p><p>As
for the next s=
tep, I suggest to have some meeting (conference) to discuss the PoC in deta=
il, and outline tasks for the near future. Also, please let me know what yo=
u think of the PoC so
far.<br></p><br>Cheers,<br>Vojtech<br><br>[1]
http://=
code.google.com/p/gwt-exporter/<p><br></p><p><...
--=_1a8d4419-a4c3-4d94-96e2-c9d519481224--
--=_156c716f-6003-47a3-bcaa-20301ab51501
Content-Type: text/x-patch; name=WIP-UI-Plugins-PoC.patch
Content-Disposition: attachment; filename=WIP-UI-Plugins-PoC.patch
Content-Transfer-Encoding: base64
RnJvbSA5NGM0NThkYzk4NThlZTcyMjBhY2Y1MzMyNDU0NGI5ODE0MGM3NTJhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBWb2p0ZWNoIFN6b2NzIDx2c3pvY3NAcmVkaGF0LmNvbT4KRGF0
ZTogVGh1LCAxOSBKdWwgMjAxMiAxNDo0ODo0MCArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIFdJUDog
VUkgUGx1Z2lucyBQb0MKCkNoYW5nZS1JZDogSWQyODgxMmRkYmU5MDU3NGRlMDE3OGYwYzA3ZGE3
MTNmZTlmZDhjZGEKU2lnbmVkLW9mZi1ieTogVm9qdGVjaCBTem9jcyA8dnN6b2NzQHJlZGhhdC5j
b20+Ci0tLQogLi4uL3NlcnZlci9nd3QvUGx1Z2luU291cmNlUGFnZVNlcnZsZXQuamF2YSAgICAg
ICAgfCAgIDQxICsrKysrKwogLi4uL3NlcnZlci9nd3QvV2ViYWRtaW5EeW5hbWljSG9zdGluZ1Nl
cnZsZXQuamF2YSAgfCAgICA0ICsKIC4uLi9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vZ2luL1N5
c3RlbU1vZHVsZS5qYXZhIHwgICAgNCArCiAuLi4vdWkvd2ViYWRtaW4vcGx1Z2luL1BsdWdpbkFw
aU1hbmFnZXIuamF2YSAgICAgICB8ICAxNDMgKysrKysrKysrKysrKysrKysrKysKIC4uLi91aS93
ZWJhZG1pbi9wbHVnaW4vUGx1Z2luRGVmaW5pdGlvbnMuamF2YSAgICAgIHwgICAzMCArKysrCiAu
Li4vdWkvd2ViYWRtaW4vcGx1Z2luL1BsdWdpbkV2ZW50SGFuZGxlci5qYXZhICAgICB8ICAgMjQg
KysrKwogLi4uL3dlYmFkbWluL3BsdWdpbi9ldmVudC9BY3Rpb25CdXR0b25DbGljay5qYXZhICAg
fCAgICA4ICsKIC4uLi9tYWluL3ZpZXcvdGFiL01haW5UYWJWaXJ0dWFsTWFjaGluZVZpZXcuamF2
YSAgIHwgICAgOCArCiAuLi4vd2ViYWRtaW4vc3JjL21haW4vd2ViYXBwL1dFQi1JTkYvd2ViLnht
bCAgICAgICB8ICAgMTAgKysKIDkgZmlsZXMgY2hhbmdlZCwgMjcyIGluc2VydGlvbnMoKyksIDAg
ZGVsZXRpb25zKC0pCiBjcmVhdGUgbW9kZSAxMDA2NDQgZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxl
cy9mcm9udGVuZC9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvZnJvbnRlbmQvc2Vy
dmVyL2d3dC9QbHVnaW5Tb3VyY2VQYWdlU2VydmxldC5qYXZhCiBjcmVhdGUgbW9kZSAxMDA2NDQg
ZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1pbi9zcmMvbWFpbi9qYXZhL29yZy9vdmly
dC9lbmdpbmUvdWkvd2ViYWRtaW4vcGx1Z2luL1BsdWdpbkFwaU1hbmFnZXIuamF2YQogY3JlYXRl
IG1vZGUgMTAwNjQ0IGZyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21haW4v
amF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL3BsdWdpbi9QbHVnaW5EZWZpbml0aW9u
cy5qYXZhCiBjcmVhdGUgbW9kZSAxMDA2NDQgZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJh
ZG1pbi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vcGx1Z2luL1Bs
dWdpbkV2ZW50SGFuZGxlci5qYXZhCiBjcmVhdGUgbW9kZSAxMDA2NDQgZnJvbnRlbmQvd2ViYWRt
aW4vbW9kdWxlcy93ZWJhZG1pbi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2Vi
YWRtaW4vcGx1Z2luL2V2ZW50L0FjdGlvbkJ1dHRvbkNsaWNrLmphdmEKCmRpZmYgLS1naXQgYS9m
cm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL2Zyb250ZW5kL3NyYy9tYWluL2phdmEvb3JnL292aXJ0
L2VuZ2luZS91aS9mcm9udGVuZC9zZXJ2ZXIvZ3d0L1BsdWdpblNvdXJjZVBhZ2VTZXJ2bGV0Lmph
dmEgYi9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL2Zyb250ZW5kL3NyYy9tYWluL2phdmEvb3Jn
L292aXJ0L2VuZ2luZS91aS9mcm9udGVuZC9zZXJ2ZXIvZ3d0L1BsdWdpblNvdXJjZVBhZ2VTZXJ2
bGV0LmphdmEKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uYzQwOGQ4ZQotLS0g
L2Rldi9udWxsCisrKyBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvZnJvbnRlbmQvc3JjL21h
aW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL2Zyb250ZW5kL3NlcnZlci9nd3QvUGx1Z2luU291
cmNlUGFnZVNlcnZsZXQuamF2YQpAQCAtMCwwICsxLDQxIEBACitwYWNrYWdlIG9yZy5vdmlydC5l
bmdpbmUudWkuZnJvbnRlbmQuc2VydmVyLmd3dDsKKworaW1wb3J0IGphdmEuaW8uSU9FeGNlcHRp
b247CitpbXBvcnQgamF2YS5pby5QcmludFdyaXRlcjsKKworaW1wb3J0IGphdmF4LnNlcnZsZXQu
aHR0cC5IdHRwU2VydmxldDsKK2ltcG9ydCBqYXZheC5zZXJ2bGV0Lmh0dHAuSHR0cFNlcnZsZXRS
ZXF1ZXN0OworaW1wb3J0IGphdmF4LnNlcnZsZXQuaHR0cC5IdHRwU2VydmxldFJlc3BvbnNlOwor
CisvKioKKyAqIFJlbmRlcnMgdGhlIEhUTUwgc291cmNlIHBhZ2UgZm9yIHRoZSBnaXZlbiBVSSBw
bHVnaW4uCisgKi8KK3B1YmxpYyBjbGFzcyBQbHVnaW5Tb3VyY2VQYWdlU2VydmxldCBleHRlbmRz
IEh0dHBTZXJ2bGV0IHsKKworICAgIHByaXZhdGUgc3RhdGljIGZpbmFsIGxvbmcgc2VyaWFsVmVy
c2lvblVJRCA9IDFMOworCisgICAgQE92ZXJyaWRlCisgICAgcHJvdGVjdGVkIHZvaWQgZG9HZXQo
SHR0cFNlcnZsZXRSZXF1ZXN0IHJlcXVlc3QsIEh0dHBTZXJ2bGV0UmVzcG9uc2UgcmVzcG9uc2Up
IHRocm93cyBJT0V4Y2VwdGlvbiB7CisgICAgICAgIFByaW50V3JpdGVyIHdyaXRlciA9IHJlc3Bv
bnNlLmdldFdyaXRlcigpOworICAgICAgICByZXNwb25zZS5zZXRDb250ZW50VHlwZSgidGV4dC9o
dG1sOyBjaGFyc2V0PVVURi04Iik7IC8vJE5PTi1OTFMtMSQKKworICAgICAgICB3cml0ZXIuYXBw
ZW5kKCI8IURPQ1RZUEUgaHRtbD48aHRtbD48aGVhZD4iKTsgLy8kTk9OLU5MUy0xJAorICAgICAg
ICB3cml0ZXIuYXBwZW5kKCI8bWV0YSBodHRwLWVxdWl2PVwiY29udGVudC10eXBlXCIgY29udGVu
dD1cInRleHQvaHRtbDsgY2hhcnNldD1VVEYtOFwiPiIpOyAvLyROT04tTkxTLTEkCisgICAgICAg
IHdyaXRlci5hcHBlbmQoIjxzY3JpcHQgdHlwZT1cInRleHQvamF2YXNjcmlwdFwiIHNyYz1cImh0
dHBzOi8vYWpheC5nb29nbGVhcGlzLmNvbS9hamF4L2xpYnMvanF1ZXJ5LzEuNy4yL2pxdWVyeS5t
aW4uanNcIj48L3NjcmlwdD4iKTsgLy8kTk9OLU5MUy0xJAorICAgICAgICB3cml0ZXIuYXBwZW5k
KCI8L2hlYWQ+PGJvZHk+Iik7IC8vJE5PTi1OTFMtMSQKKworICAgICAgICB3cml0ZXIuYXBwZW5k
KCI8c2NyaXB0IHR5cGU9XCJ0ZXh0L2phdmFzY3JpcHRcIj4iKTsgLy8kTk9OLU5MUy0xJAorICAg
ICAgICB3cml0ZXIuYXBwZW5kKCIoZnVuY3Rpb24oIHBsdWdpbkFwaSwgcGx1Z2luQ29uZmlnICkg
eyIpOyAvLyROT04tTkxTLTEkCisgICAgICAgIHdyaXRlci5hcHBlbmQoIiAgd2luZG93LmFsZXJ0
KCdJbnZva2luZyBhY3R1YWwgcGx1Z2luIGNvZGUhJyk7Iik7IC8vJE5PTi1OTFMtMSQKKyAgICAg
ICAgd3JpdGVyLmFwcGVuZCgiICB3aW5kb3cuYWxlcnQoJ1JlYWRpbmcgcGx1Z2luIGNvbmZpZ3Vy
YXRpb246ICcgKyBwbHVnaW5Db25maWcuZm9vKTsiKTsgLy8kTk9OLU5MUy0xJAorICAgICAgICB3
cml0ZXIuYXBwZW5kKCIgIHBsdWdpbkFwaS5wbHVnaW5zWydteVBsdWdpbiddID0geyIpOyAvLyRO
T04tTkxTLTEkCisgICAgICAgIHdyaXRlci5hcHBlbmQoIiAgICBBY3Rpb25CdXR0b25DbGljazog
ZnVuY3Rpb24oY29udGV4dE9iamVjdCkgeyB3aW5kb3cuYWxlcnQoJ1dvb2hvbyEnKTsgfSIpOyAv
LyROT04tTkxTLTEkCisgICAgICAgIHdyaXRlci5hcHBlbmQoIiAgfTsiKTsgLy8kTk9OLU5MUy0x
JAorICAgICAgICB3cml0ZXIuYXBwZW5kKCIgIHBsdWdpbkFwaS5yZWFkeSgnbXlQbHVnaW4nKTsi
KTsgLy8kTk9OLU5MUy0xJAorICAgICAgICB3cml0ZXIuYXBwZW5kKCJ9KSAoIHBhcmVudC5wbHVn
aW5BcGksIHsgXCJmb29cIjogMTIzIH0gKTsiKTsgLy8kTk9OLU5MUy0xJAorICAgICAgICB3cml0
ZXIuYXBwZW5kKCI8L3NjcmlwdD4iKTsgLy8kTk9OLU5MUy0xJAorCisgICAgICAgIHdyaXRlci5h
cHBlbmQoIjwvYm9keT48L2h0bWw+Iik7IC8vJE5PTi1OTFMtMSQKKyAgICB9CisKK30KZGlmZiAt
LWdpdCBhL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvZnJvbnRlbmQvc3JjL21haW4vamF2YS9v
cmcvb3ZpcnQvZW5naW5lL3VpL2Zyb250ZW5kL3NlcnZlci9nd3QvV2ViYWRtaW5EeW5hbWljSG9z
dGluZ1NlcnZsZXQuamF2YSBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvZnJvbnRlbmQvc3Jj
L21haW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL2Zyb250ZW5kL3NlcnZlci9nd3QvV2ViYWRt
aW5EeW5hbWljSG9zdGluZ1NlcnZsZXQuamF2YQppbmRleCA0MjhkY2M1Li5kY2FmNDlhIDEwMDY0
NAotLS0gYS9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL2Zyb250ZW5kL3NyYy9tYWluL2phdmEv
b3JnL292aXJ0L2VuZ2luZS91aS9mcm9udGVuZC9zZXJ2ZXIvZ3d0L1dlYmFkbWluRHluYW1pY0hv
c3RpbmdTZXJ2bGV0LmphdmEKKysrIGIvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy9mcm9udGVu
ZC9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvZnJvbnRlbmQvc2VydmVyL2d3dC9X
ZWJhZG1pbkR5bmFtaWNIb3N0aW5nU2VydmxldC5qYXZhCkBAIC0zNiw2ICszNiwxMCBAQCBwdWJs
aWMgY2xhc3MgV2ViYWRtaW5EeW5hbWljSG9zdGluZ1NlcnZsZXQgZXh0ZW5kcyBHd3REeW5hbWlj
SG9zdFBhZ2VTZXJ2bGV0IHsKICAgICAgICAgICAgIGFwcE1vZGVEYXRhLnB1dCgidmFsdWUiLCBT
dHJpbmcudmFsdWVPZihhcHBsaWNhdGlvbk1vZGUpKTsgLy8kTk9OLU5MUy0xJAogICAgICAgICAg
ICAgd3JpdGVKc09iamVjdCh3cml0ZXIsICJhcHBsaWNhdGlvbk1vZGUiLCBhcHBNb2RlRGF0YSk7
IC8vJE5PTi1OTFMtMSQKICAgICAgICAgfQorCisgICAgICAgIE1hcDxTdHJpbmcsIFN0cmluZz4g
cGx1Z2luRGVmaW5pdGlvbnMgPSBuZXcgSGFzaE1hcDxTdHJpbmcsIFN0cmluZz4oKTsKKyAgICAg
ICAgcGx1Z2luRGVmaW5pdGlvbnMucHV0KCJteVBsdWdpbiIsICIvd2ViYWRtaW4vd2ViYWRtaW4v
UGx1Z2luU291cmNlUGFnZT9wbHVnaW49bXlQbHVnaW4iKTsgLy8kTk9OLU5MUy0xJCAvLyROT04t
TkxTLTIkCisgICAgICAgIHdyaXRlSnNPYmplY3Qod3JpdGVyLCAicGx1Z2luRGVmaW5pdGlvbnMi
LCBwbHVnaW5EZWZpbml0aW9ucyk7IC8vJE5PTi1OTFMtMSQKICAgICB9CiAKICAgICBwcml2YXRl
IEludGVnZXIgZ2V0QXBwbGljYXRpb25Nb2RlKEh0dHBTZXJ2bGV0UmVxdWVzdCByZXF1ZXN0KSB7
CmRpZmYgLS1naXQgYS9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWlu
L2phdmEvb3JnL292aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9naW4vU3lzdGVtTW9kdWxlLmphdmEg
Yi9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWluL2phdmEvb3JnL292
aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9naW4vU3lzdGVtTW9kdWxlLmphdmEKaW5kZXggMzA2OWI5
OS4uNzg5NjNhZCAxMDA2NDQKLS0tIGEvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1p
bi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vZ2luL1N5c3RlbU1v
ZHVsZS5qYXZhCisrKyBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21h
aW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL2dpbi9TeXN0ZW1Nb2R1bGUuamF2
YQpAQCAtOSw2ICs5LDggQEAgaW1wb3J0IG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4uQXBw
bGljYXRpb25SZXNvdXJjZXM7CiBpbXBvcnQgb3JnLm92aXJ0LmVuZ2luZS51aS53ZWJhZG1pbi5B
cHBsaWNhdGlvblRlbXBsYXRlczsKIGltcG9ydCBvcmcub3ZpcnQuZW5naW5lLnVpLndlYmFkbWlu
LnBsYWNlLkFwcGxpY2F0aW9uUGxhY2VzOwogaW1wb3J0IG9yZy5vdmlydC5lbmdpbmUudWkud2Vi
YWRtaW4ucGxhY2UuV2ViQWRtaW5QbGFjZU1hbmFnZXI7CitpbXBvcnQgb3JnLm92aXJ0LmVuZ2lu
ZS51aS53ZWJhZG1pbi5wbHVnaW4uUGx1Z2luQXBpTWFuYWdlcjsKK2ltcG9ydCBvcmcub3ZpcnQu
ZW5naW5lLnVpLndlYmFkbWluLnBsdWdpbi5QbHVnaW5FdmVudEhhbmRsZXI7CiBpbXBvcnQgb3Jn
Lm92aXJ0LmVuZ2luZS51aS53ZWJhZG1pbi5zeXN0ZW0uQXBwbGljYXRpb25Jbml0OwogaW1wb3J0
IG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4uc3lzdGVtLkludGVybmFsQ29uZmlndXJhdGlv
bjsKIApAQCAtMzEsNiArMzMsOCBAQCBwdWJsaWMgY2xhc3MgU3lzdGVtTW9kdWxlIGV4dGVuZHMg
QmFzZVN5c3RlbU1vZHVsZSB7CiAgICAgICAgIGJpbmQoUGxhY2VNYW5hZ2VyLmNsYXNzKS50byhX
ZWJBZG1pblBsYWNlTWFuYWdlci5jbGFzcykuaW4oU2luZ2xldG9uLmNsYXNzKTsKICAgICAgICAg
YmluZChBcHBsaWNhdGlvbkluaXQuY2xhc3MpLmFzRWFnZXJTaW5nbGV0b24oKTsKICAgICAgICAg
YmluZChJbnRlcm5hbENvbmZpZ3VyYXRpb24uY2xhc3MpLmFzRWFnZXJTaW5nbGV0b24oKTsKKyAg
ICAgICAgYmluZChQbHVnaW5BcGlNYW5hZ2VyLmNsYXNzKS5hc0VhZ2VyU2luZ2xldG9uKCk7Cisg
ICAgICAgIGJpbmQoUGx1Z2luRXZlbnRIYW5kbGVyLmNsYXNzKS5hc0VhZ2VyU2luZ2xldG9uKCk7
CiAgICAgfQogCiAgICAgdm9pZCBiaW5kQ29uZmlndXJhdGlvbigpIHsKZGlmZiAtLWdpdCBhL2Zy
b250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21haW4vamF2YS9vcmcvb3ZpcnQv
ZW5naW5lL3VpL3dlYmFkbWluL3BsdWdpbi9QbHVnaW5BcGlNYW5hZ2VyLmphdmEgYi9mcm9udGVu
ZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2lu
ZS91aS93ZWJhZG1pbi9wbHVnaW4vUGx1Z2luQXBpTWFuYWdlci5qYXZhCm5ldyBmaWxlIG1vZGUg
MTAwNjQ0CmluZGV4IDAwMDAwMDAuLjBiYmRkNjgKLS0tIC9kZXYvbnVsbAorKysgYi9mcm9udGVu
ZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2lu
ZS91aS93ZWJhZG1pbi9wbHVnaW4vUGx1Z2luQXBpTWFuYWdlci5qYXZhCkBAIC0wLDAgKzEsMTQz
IEBACitwYWNrYWdlIG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4ucGx1Z2luOworCitpbXBv
cnQgamF2YS51dGlsLkhhc2hNYXA7CitpbXBvcnQgamF2YS51dGlsLk1hcDsKK2ltcG9ydCBqYXZh
LnV0aWwubG9nZ2luZy5Mb2dnZXI7CisKK2ltcG9ydCBjb20uZ29vZ2xlLmd3dC5jb3JlLmNsaWVu
dC5KYXZhU2NyaXB0T2JqZWN0OworaW1wb3J0IGNvbS5nb29nbGUuZ3d0LmNvcmUuY2xpZW50Lkpz
QXJyYXlTdHJpbmc7CitpbXBvcnQgY29tLmdvb2dsZS5nd3QuZG9tLmNsaWVudC5Eb2N1bWVudDsK
K2ltcG9ydCBjb20uZ29vZ2xlLmd3dC5kb20uY2xpZW50LklGcmFtZUVsZW1lbnQ7CitpbXBvcnQg
Y29tLmdvb2dsZS5nd3QuZG9tLmNsaWVudC5TdHlsZS5Cb3JkZXJTdHlsZTsKK2ltcG9ydCBjb20u
Z29vZ2xlLmd3dC5kb20uY2xpZW50LlN0eWxlLlBvc2l0aW9uOworaW1wb3J0IGNvbS5nb29nbGUu
Z3d0LmRvbS5jbGllbnQuU3R5bGUuVW5pdDsKKworLyoqCisgKiBUaGUgbWFpbiBjb21wb25lbnQg
b2YgV2ViQWRtaW4gVUkgcGx1Z2luIGluZnJhc3RydWN0dXJlLgorICogPHA+CisgKiBTaG91bGQg
YmUgYm91bmQgYXMgR0lOIGVhZ2VyIHNpbmdsZXRvbiwgY3JlYXRlZCBlYXJseSBvbiBkdXJpbmcg
YXBwbGljYXRpb24gc3RhcnR1cC4KKyAqLworcHVibGljIGNsYXNzIFBsdWdpbkFwaU1hbmFnZXIg
eworCisgICAgcHJpdmF0ZSBzdGF0aWMgZmluYWwgTG9nZ2VyIGxvZ2dlciA9IExvZ2dlci5nZXRM
b2dnZXIoUGx1Z2luQXBpTWFuYWdlci5jbGFzcy5nZXROYW1lKCkpOworCisgICAgLy8gTWFwcyBw
bHVnaW4gbmFtZXMgdG8gY29ycmVzcG9uZGluZyBpZnJhbWUgZWxlbWVudHMKKyAgICBwcml2YXRl
IGZpbmFsIE1hcDxTdHJpbmcsIElGcmFtZUVsZW1lbnQ+IHBsdWdpbklGcmFtZXMgPSBuZXcgSGFz
aE1hcDxTdHJpbmcsIElGcmFtZUVsZW1lbnQ+KCk7CisKKyAgICAvLyBNYXBzIHBsdWdpbiBuYW1l
cyB0byBjb3JyZXNwb25kaW5nIHBsdWdpbiBvYmplY3RzIChvbmx5IGZvciBwbHVnaW5zIHdoaWNo
IGFyZSBjdXJyZW50bHkgcmVhZHkpCisgICAgcHJpdmF0ZSBmaW5hbCBNYXA8U3RyaW5nLCBKYXZh
U2NyaXB0T2JqZWN0PiBwbHVnaW5PYmplY3RzID0gbmV3IEhhc2hNYXA8U3RyaW5nLCBKYXZhU2Ny
aXB0T2JqZWN0PigpOworCisgICAgcHVibGljIFBsdWdpbkFwaU1hbmFnZXIoKSB7CisgICAgICAg
IGV4cG9zZVBsdWdpbkFwaSgpOworICAgICAgICBsb2FkUGx1Z2lucygpOworICAgIH0KKworICAg
IC8qKgorICAgICAqIEludm9rZXMgdGhlIGdpdmVuIGV2ZW50IGhhbmRsZXIgZnVuY3Rpb24gb24g
YWxsIHBsdWdpbnMgd2hpY2ggYXJlIGN1cnJlbnRseSByZWFkeS4KKyAgICAgKi8KKyAgICBwdWJs
aWMgdm9pZCBpbnZva2VQbHVnaW5zKFN0cmluZyBmdW5jdGlvbk5hbWUsIEphdmFTY3JpcHRPYmpl
Y3QgY29udGV4dE9iamVjdCkgeworICAgICAgICBmb3IgKEphdmFTY3JpcHRPYmplY3QgcGx1Z2lu
T2JqZWN0IDogcGx1Z2luT2JqZWN0cy52YWx1ZXMoKSkgeworICAgICAgICAgICAgaW52b2tlUGx1
Z2luKHBsdWdpbk9iamVjdCwgZnVuY3Rpb25OYW1lLCBjb250ZXh0T2JqZWN0KTsKKyAgICAgICAg
fQorICAgIH0KKworICAgIG5hdGl2ZSB2b2lkIGludm9rZVBsdWdpbihKYXZhU2NyaXB0T2JqZWN0
IHBsdWdpbk9iamVjdCwgU3RyaW5nIGZ1bmN0aW9uTmFtZSwgSmF2YVNjcmlwdE9iamVjdCBjb250
ZXh0T2JqZWN0KSAvKi17CisgICAgICAgIGlmIChjb250ZXh0T2JqZWN0ICE9IG51bGwpIHsKKyAg
ICAgICAgICAgIHBsdWdpbk9iamVjdFtmdW5jdGlvbk5hbWVdKGNvbnRleHRPYmplY3QpOworICAg
ICAgICB9IGVsc2UgeworICAgICAgICAgICAgcGx1Z2luT2JqZWN0W2Z1bmN0aW9uTmFtZV0oKTsK
KyAgICAgICAgfQorICAgIH0tKi87CisKKyAgICAvKioKKyAgICAgKiBMb2FkcyBhbGwgcGx1Z2lu
cyB0aGF0IHdlcmUgZGV0ZWN0ZWQgd2hlbiBzZXJ2aW5nIFdlYkFkbWluIGhvc3QgcGFnZS4KKyAg
ICAgKi8KKyAgICB2b2lkIGxvYWRQbHVnaW5zKCkgeworICAgICAgICBQbHVnaW5EZWZpbml0aW9u
cyBkZWZzID0gUGx1Z2luRGVmaW5pdGlvbnMuaW5zdGFuY2UoKTsKKworICAgICAgICBpZiAoZGVm
cyAhPSBudWxsKSB7CisgICAgICAgICAgICBKc0FycmF5U3RyaW5nIHBsdWdpbk5hbWVzID0gZGVm
cy5nZXRQbHVnaW5OYW1lcygpOworCisgICAgICAgICAgICBmb3IgKGludCBpID0gMDsgaSA8IHBs
dWdpbk5hbWVzLmxlbmd0aCgpOyBpKyspIHsKKyAgICAgICAgICAgICAgICBTdHJpbmcgbmFtZSA9
IHBsdWdpbk5hbWVzLmdldChpKTsKKyAgICAgICAgICAgICAgICBTdHJpbmcgc291cmNlUGFnZVVy
bCA9IGRlZnMuZ2V0UGx1Z2luU291cmNlUGFnZVVybChuYW1lKTsKKworICAgICAgICAgICAgICAg
IGxvZ2dlci5pbmZvKCJMb2FkaW5nIHBsdWdpbiBbIiArIG5hbWUgKyAiXSBmcm9tIFVSTCAiICsg
c291cmNlUGFnZVVybCk7IC8vJE5PTi1OTFMtMSQgLy8kTk9OLU5MUy0yJAorICAgICAgICAgICAg
ICAgIGxvYWRQbHVnaW4obmFtZSwgc291cmNlUGFnZVVybCk7CisgICAgICAgICAgICB9CisgICAg
ICAgIH0KKyAgICB9CisKKyAgICAvKioKKyAgICAgKiBMb2FkcyBhIHBsdWdpbiB1c2luZyBpdHMg
c291cmNlIHBhZ2UgKEhUTUwgcGFnZSB0aGF0IGV4ZWN1dGVzIHRoZSBhY3R1YWwgcGx1Z2luIGNv
ZGUpLgorICAgICAqIDxwPgorICAgICAqIFdlYkFkbWluIHJlcXVpcmVzIGFsbCBwbHVnaW5zIHRv
IGhhdmUgYSBzb3VyY2UgcGFnZSBiZWNhdXNlIGVhY2ggcGx1Z2luIHJ1bnMgd2l0aGluIHRoZSBj
b250ZXh0IG9mIGFuIGlmcmFtZS4KKyAgICAgKiA8cD4KKyAgICAgKiBOb3RlIHRoYXQgcGx1Z2lu
IHNvdXJjZSBwYWdlIFVSTHMgYXJlIGFsd2F5cyByZWxhdGl2ZSB0byBKQm9zcyBzZXJ2ZXIgcm9v
dCBwYXRoLiBTb3VyY2UgcGFnZSBVUkxzIG11c3QgdGhlcmVmb3JlCisgICAgICogYWx3YXlzIGJl
Z2luIHdpdGggc2xhc2ggKHtAY29kZSAvfSkgY2hhcmFjdGVyLiBUaGlzIGFsbG93cyBXZWJBZG1p
biBob3N0IHBhZ2UgYW5kIGluZGl2aWR1YWwgcGx1Z2luIHNvdXJjZSBwYWdlcworICAgICAqIHRv
IHNoYXJlIHRoZSBzYW1lIG9yaWdpbiAocHJvdG9jb2wsIGRvbWFpbiwgcG9ydCkgYW5kIGF2b2lk
IGNyb3NzLWRvbWFpbiB3aW5kb3cvaWZyYW1lIGNvbW11bmljYXRpb24gaXNzdWVzLgorICAgICAq
LworICAgIHZvaWQgbG9hZFBsdWdpbihTdHJpbmcgcGx1Z2luTmFtZSwgU3RyaW5nIHBsdWdpblNv
dXJjZVBhZ2VVcmwpIHsKKyAgICAgICAgaWYgKCFwbHVnaW5Tb3VyY2VQYWdlVXJsLnN0YXJ0c1dp
dGgoIi8iKSkgeyAvLyROT04tTkxTLTEkCisgICAgICAgICAgICBsb2dnZXIud2FybmluZygiQXR0
ZW1wdGluZyB0byBsb2FkIHBsdWdpbiBbIiArIHBsdWdpbk5hbWUgKyAiXSB1c2luZyBpbnZhbGlk
IFVSTCAiICsgcGx1Z2luU291cmNlUGFnZVVybCk7IC8vJE5PTi1OTFMtMSQgLy8kTk9OLU5MUy0y
JAorICAgICAgICAgICAgcmV0dXJuOworICAgICAgICB9CisKKyAgICAgICAgaWYgKHBsdWdpbklG
cmFtZXMuY29udGFpbnNLZXkocGx1Z2luTmFtZSkpIHsKKyAgICAgICAgICAgIGxvZ2dlci53YXJu
aW5nKCJQbHVnaW4gWyIgKyBwbHVnaW5OYW1lICsgIl0gaXMgYWxyZWFkeSBsb2FkZWQiKTsgLy8k
Tk9OLU5MUy0xJCAvLyROT04tTkxTLTIkCisgICAgICAgICAgICByZXR1cm47CisgICAgICAgIH0K
KworICAgICAgICAvLyBDcmVhdGUgYW4gaWZyYW1lIHVzZWQgdG8gbG9hZCB0aGUgcGx1Z2luIHNv
dXJjZSBwYWdlCisgICAgICAgIElGcmFtZUVsZW1lbnQgaWZyYW1lID0gRG9jdW1lbnQuZ2V0KCku
Y3JlYXRlSUZyYW1lRWxlbWVudCgpOworICAgICAgICBpZnJhbWUuc2V0U3JjKHBsdWdpblNvdXJj
ZVBhZ2VVcmwpOworICAgICAgICBpZnJhbWUuc2V0RnJhbWVCb3JkZXIoMCk7CisgICAgICAgIGlm
cmFtZS5nZXRTdHlsZSgpLnNldFBvc2l0aW9uKFBvc2l0aW9uLkFCU09MVVRFKTsKKyAgICAgICAg
aWZyYW1lLmdldFN0eWxlKCkuc2V0V2lkdGgoMCwgVW5pdC5QVCk7CisgICAgICAgIGlmcmFtZS5n
ZXRTdHlsZSgpLnNldEhlaWdodCgwLCBVbml0LlBUKTsKKyAgICAgICAgaWZyYW1lLmdldFN0eWxl
KCkuc2V0Qm9yZGVyU3R5bGUoQm9yZGVyU3R5bGUuTk9ORSk7CisgICAgICAgIHBsdWdpbklGcmFt
ZXMucHV0KHBsdWdpbk5hbWUsIGlmcmFtZSk7CisKKyAgICAgICAgLy8gQXR0YWNoIHRoZSBpZnJh
bWUgdG8gRE9NIGRvY3VtZW50IGJvZHkKKyAgICAgICAgRG9jdW1lbnQuZ2V0KCkuZ2V0Qm9keSgp
LmFwcGVuZENoaWxkKGlmcmFtZSk7CisgICAgfQorCisgICAgLyoqCisgICAgICogSW5kaWNhdGVz
IHRoYXQgdGhlIGdpdmVuIHBsdWdpbiBpcyByZWFkeSBmb3IgdXNlLgorICAgICAqIDxwPgorICAg
ICAqIE5vdGUgdGhhdCBldmVudCBoYW5kbGVyIGZ1bmN0aW9ucyB3aWxsIGJlIGludm9rZWQgb25s
eSBvbiBwbHVnaW5zIHdoaWNoIGFyZSBjdXJyZW50bHkgcmVhZHkuCisgICAgICovCisgICAgdm9p
ZCBwbHVnaW5SZWFkeShTdHJpbmcgcGx1Z2luTmFtZSwgSmF2YVNjcmlwdE9iamVjdCBwbHVnaW5P
YmplY3QpIHsKKyAgICAgICAgaWYgKHBsdWdpbk5hbWUgPT0gbnVsbCkgeworICAgICAgICAgICAg
bG9nZ2VyLndhcm5pbmcoIlBsdWdpbiBuYW1lIGlzIG51bGwgb3IgdW5kZWZpbmVkIik7IC8vJE5P
Ti1OTFMtMSQKKyAgICAgICAgICAgIHJldHVybjsKKyAgICAgICAgfQorCisgICAgICAgIGlmICgh
cGx1Z2luSUZyYW1lcy5jb250YWluc0tleShwbHVnaW5OYW1lKSkgeworICAgICAgICAgICAgbG9n
Z2VyLndhcm5pbmcoIlBsdWdpbiBbIiArIHBsdWdpbk5hbWUgKyAiXSByZXBvcnRzIGluIGFzIHJl
YWR5LCBidXQgaGFzIG5vIGlmcmFtZSBhc3NvY2lhdGVkIik7IC8vJE5PTi1OTFMtMSQgLy8kTk9O
LU5MUy0yJAorICAgICAgICAgICAgcmV0dXJuOworICAgICAgICB9CisKKyAgICAgICAgcGx1Z2lu
T2JqZWN0cy5wdXQocGx1Z2luTmFtZSwgcGx1Z2luT2JqZWN0KTsKKyAgICB9CisKKyAgICBuYXRp
dmUgdm9pZCBleHBvc2VQbHVnaW5BcGkoKSAvKi17CisgICAgICAgIHZhciBpbnN0YW5jZSA9IHRo
aXM7CisKKyAgICAgICAgLy8gRXhwb3NlIHRoZSBnbG9iYWwgcGx1Z2luQXBpIG9iamVjdAorICAg
ICAgICAkd25kLnBsdWdpbkFwaSA9IHsKKworICAgICAgICAgICAgLy8gUGx1Z2lucyB3aWxsIHJl
Z2lzdGVyIHRoZW1zZWx2ZXMgaW50byB0aGlzIG9iamVjdCBieSBhZGRpbmcgbmV3IHByb3BlcnR5
OgorICAgICAgICAgICAgLy8gLSBwcm9wZXJ0eSBuYW1lIGlzIHRoZSBuYW1lIG9mIHRoZSBwbHVn
aW4KKyAgICAgICAgICAgIC8vIC0gcHJvcGVydHkgdmFsdWUgaXMgdGhlIHBsdWdpbiBvYmplY3Qg
Y29udGFpbmluZyBldmVudCBoYW5kbGVyIGZ1bmN0aW9ucworICAgICAgICAgICAgcGx1Z2luczog
e30sCisKKyAgICAgICAgICAgIHJlYWR5OiBmdW5jdGlvbihwbHVnaW5OYW1lKSB7CisgICAgICAg
ICAgICAgICAgdmFyIHBsdWdpbk9iamVjdCA9IHRoaXMucGx1Z2luc1twbHVnaW5OYW1lXTsKKyAg
ICAgICAgICAgICAgICBpbnN0YW5jZS5Ab3JnLm92aXJ0LmVuZ2luZS51aS53ZWJhZG1pbi5wbHVn
aW4uUGx1Z2luQXBpTWFuYWdlcjo6cGx1Z2luUmVhZHkoTGphdmEvbGFuZy9TdHJpbmc7TGNvbS9n
b29nbGUvZ3d0L2NvcmUvY2xpZW50L0phdmFTY3JpcHRPYmplY3Q7KShwbHVnaW5OYW1lLHBsdWdp
bk9iamVjdCk7CisgICAgICAgICAgICB9CisKKyAgICAgICAgfTsKKyAgICB9LSovOworCit9CmRp
ZmYgLS1naXQgYS9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWluL2ph
dmEvb3JnL292aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9wbHVnaW4vUGx1Z2luRGVmaW5pdGlvbnMu
amF2YSBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21haW4vamF2YS9v
cmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL3BsdWdpbi9QbHVnaW5EZWZpbml0aW9ucy5qYXZh
Cm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmQxMTE4Y2IKLS0tIC9kZXYvbnVs
bAorKysgYi9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9tYWluL2phdmEv
b3JnL292aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9wbHVnaW4vUGx1Z2luRGVmaW5pdGlvbnMuamF2
YQpAQCAtMCwwICsxLDMwIEBACitwYWNrYWdlIG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4u
cGx1Z2luOworCitpbXBvcnQgY29tLmdvb2dsZS5nd3QuY29yZS5jbGllbnQuSmF2YVNjcmlwdE9i
amVjdDsKK2ltcG9ydCBjb20uZ29vZ2xlLmd3dC5jb3JlLmNsaWVudC5Kc0FycmF5U3RyaW5nOwor
CisvKioKKyAqIE92ZXJsYXkgdHlwZSBmb3Ige0Bjb2RlIHBsdWdpbkRlZmluaXRpb25zfSBnbG9i
YWwgSlMgb2JqZWN0LgorICovCitwdWJsaWMgZmluYWwgY2xhc3MgUGx1Z2luRGVmaW5pdGlvbnMg
ZXh0ZW5kcyBKYXZhU2NyaXB0T2JqZWN0IHsKKworICAgIHByb3RlY3RlZCBQbHVnaW5EZWZpbml0
aW9ucygpIHsKKyAgICB9CisKKyAgICBwdWJsaWMgc3RhdGljIG5hdGl2ZSBQbHVnaW5EZWZpbml0
aW9ucyBpbnN0YW5jZSgpIC8qLXsKKyAgICAgICAgcmV0dXJuICR3bmQucGx1Z2luRGVmaW5pdGlv
bnM7CisgICAgfS0qLzsKKworICAgIHB1YmxpYyBuYXRpdmUgSnNBcnJheVN0cmluZyBnZXRQbHVn
aW5OYW1lcygpIC8qLXsKKyAgICAgICAgdmFyIHBsdWdpbk5hbWVzID0gW107CisgICAgICAgIGZv
ciAodmFyIGtleSBpbiB0aGlzKSB7CisgICAgICAgICAgICBwbHVnaW5OYW1lcy5wdXNoKGtleSk7
CisgICAgICAgIH0KKyAgICAgICAgcmV0dXJuIHBsdWdpbk5hbWVzOworICAgIH0tKi87CisKKyAg
ICBwdWJsaWMgbmF0aXZlIFN0cmluZyBnZXRQbHVnaW5Tb3VyY2VQYWdlVXJsKFN0cmluZyBwbHVn
aW5OYW1lKSAvKi17CisgICAgICAgIHJldHVybiB0aGlzW3BsdWdpbk5hbWVdOworICAgIH0tKi87
CisKK30KZGlmZiAtLWdpdCBhL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3Jj
L21haW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL3BsdWdpbi9QbHVnaW5FdmVu
dEhhbmRsZXIuamF2YSBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21h
aW4vamF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL3BsdWdpbi9QbHVnaW5FdmVudEhh
bmRsZXIuamF2YQpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi45ZjUwMWFjCi0t
LSAvZGV2L251bGwKKysrIGIvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1pbi9zcmMv
bWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vcGx1Z2luL1BsdWdpbkV2ZW50
SGFuZGxlci5qYXZhCkBAIC0wLDAgKzEsMjQgQEAKK3BhY2thZ2Ugb3JnLm92aXJ0LmVuZ2luZS51
aS53ZWJhZG1pbi5wbHVnaW47CisKK2ltcG9ydCBvcmcub3ZpcnQuZW5naW5lLnVpLndlYmFkbWlu
LnBsdWdpbi5ldmVudC5BY3Rpb25CdXR0b25DbGlja0V2ZW50OworaW1wb3J0IG9yZy5vdmlydC5l
bmdpbmUudWkud2ViYWRtaW4ucGx1Z2luLmV2ZW50LkFjdGlvbkJ1dHRvbkNsaWNrRXZlbnQuQWN0
aW9uQnV0dG9uQ2xpY2tIYW5kbGVyOworCitpbXBvcnQgY29tLmdvb2dsZS5nd3QuZXZlbnQuc2hh
cmVkLkV2ZW50QnVzOworaW1wb3J0IGNvbS5nb29nbGUuaW5qZWN0LkluamVjdDsKKworLyoqCisg
KiBIYW5kbGVzIFdlYkFkbWluIGFwcGxpY2F0aW9uIGV2ZW50cyB0byBiZSBjb25zdW1lZCBieSBV
SSBwbHVnaW5zLgorICovCitwdWJsaWMgY2xhc3MgUGx1Z2luRXZlbnRIYW5kbGVyIHsKKworICAg
IEBJbmplY3QKKyAgICBwdWJsaWMgUGx1Z2luRXZlbnRIYW5kbGVyKEV2ZW50QnVzIGV2ZW50QnVz
LCBmaW5hbCBQbHVnaW5BcGlNYW5hZ2VyIG1hbmFnZXIpIHsKKyAgICAgICAgZXZlbnRCdXMuYWRk
SGFuZGxlcihBY3Rpb25CdXR0b25DbGlja0V2ZW50LmdldFR5cGUoKSwgbmV3IEFjdGlvbkJ1dHRv
bkNsaWNrSGFuZGxlcigpIHsKKyAgICAgICAgICAgIEBPdmVycmlkZQorICAgICAgICAgICAgcHVi
bGljIHZvaWQgb25BY3Rpb25CdXR0b25DbGljayhBY3Rpb25CdXR0b25DbGlja0V2ZW50IGV2ZW50
KSB7CisgICAgICAgICAgICAgICAgbWFuYWdlci5pbnZva2VQbHVnaW5zKCJBY3Rpb25CdXR0b25D
bGljayIsIG51bGwpOyAvLyROT04tTkxTLTEkCisgICAgICAgICAgICB9CisgICAgICAgIH0pOwor
ICAgIH0KKworfQpkaWZmIC0tZ2l0IGEvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1p
bi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vcGx1Z2luL2V2ZW50
L0FjdGlvbkJ1dHRvbkNsaWNrLmphdmEgYi9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFk
bWluL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9wbHVnaW4vZXZl
bnQvQWN0aW9uQnV0dG9uQ2xpY2suamF2YQpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAw
MDAwLi42MTQ1YjNkCi0tLSAvZGV2L251bGwKKysrIGIvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxl
cy93ZWJhZG1pbi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vcGx1
Z2luL2V2ZW50L0FjdGlvbkJ1dHRvbkNsaWNrLmphdmEKQEAgLTAsMCArMSw4IEBACitwYWNrYWdl
IG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4ucGx1Z2luLmV2ZW50OworCitpbXBvcnQgY29t
Lmd3dHBsYXRmb3JtLmRpc3BhdGNoLmFubm90YXRpb24uR2VuRXZlbnQ7CisKK0BHZW5FdmVudAor
cHVibGljIGNsYXNzIEFjdGlvbkJ1dHRvbkNsaWNrIHsKKworfQpkaWZmIC0tZ2l0IGEvZnJvbnRl
bmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1pbi9zcmMvbWFpbi9qYXZhL29yZy9vdmlydC9lbmdp
bmUvdWkvd2ViYWRtaW4vc2VjdGlvbi9tYWluL3ZpZXcvdGFiL01haW5UYWJWaXJ0dWFsTWFjaGlu
ZVZpZXcuamF2YSBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21haW4v
amF2YS9vcmcvb3ZpcnQvZW5naW5lL3VpL3dlYmFkbWluL3NlY3Rpb24vbWFpbi92aWV3L3RhYi9N
YWluVGFiVmlydHVhbE1hY2hpbmVWaWV3LmphdmEKaW5kZXggODc4OGNjNy4uMDE4ZDMxYyAxMDA2
NDQKLS0tIGEvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxlcy93ZWJhZG1pbi9zcmMvbWFpbi9qYXZh
L29yZy9vdmlydC9lbmdpbmUvdWkvd2ViYWRtaW4vc2VjdGlvbi9tYWluL3ZpZXcvdGFiL01haW5U
YWJWaXJ0dWFsTWFjaGluZVZpZXcuamF2YQorKysgYi9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVz
L3dlYmFkbWluL3NyYy9tYWluL2phdmEvb3JnL292aXJ0L2VuZ2luZS91aS93ZWJhZG1pbi9zZWN0
aW9uL21haW4vdmlldy90YWIvTWFpblRhYlZpcnR1YWxNYWNoaW5lVmlldy5qYXZhCkBAIC0xNyw2
ICsxNyw4IEBAIGltcG9ydCBvcmcub3ZpcnQuZW5naW5lLnVpLnVpY29tbW9ud2ViLm1vZGVscy52
bXMuQ29uc29sZU1vZGVsOwogaW1wb3J0IG9yZy5vdmlydC5lbmdpbmUudWkudWljb21tb253ZWIu
bW9kZWxzLnZtcy5WbUxpc3RNb2RlbDsKIGltcG9ydCBvcmcub3ZpcnQuZW5naW5lLnVpLndlYmFk
bWluLkFwcGxpY2F0aW9uQ29uc3RhbnRzOwogaW1wb3J0IG9yZy5vdmlydC5lbmdpbmUudWkud2Vi
YWRtaW4uQXBwbGljYXRpb25SZXNvdXJjZXM7CitpbXBvcnQgb3JnLm92aXJ0LmVuZ2luZS51aS53
ZWJhZG1pbi5naW4uQ2xpZW50R2luamVjdG9yUHJvdmlkZXI7CitpbXBvcnQgb3JnLm92aXJ0LmVu
Z2luZS51aS53ZWJhZG1pbi5wbHVnaW4uZXZlbnQuQWN0aW9uQnV0dG9uQ2xpY2tFdmVudDsKIGlt
cG9ydCBvcmcub3ZpcnQuZW5naW5lLnVpLndlYmFkbWluLnNlY3Rpb24ubWFpbi5wcmVzZW50ZXIu
dGFiLk1haW5UYWJWaXJ0dWFsTWFjaGluZVByZXNlbnRlcjsKIGltcG9ydCBvcmcub3ZpcnQuZW5n
aW5lLnVpLndlYmFkbWluLnNlY3Rpb24ubWFpbi52aWV3LkFic3RyYWN0TWFpblRhYldpdGhEZXRh
aWxzVGFibGVWaWV3OwogaW1wb3J0IG9yZy5vdmlydC5lbmdpbmUudWkud2ViYWRtaW4udWljb21t
b24uUmVwb3J0QWN0aW9uc0hlbHBlcjsKQEAgLTE2Myw2ICsxNjUsMTIgQEAgcHVibGljIGNsYXNz
IE1haW5UYWJWaXJ0dWFsTWFjaGluZVZpZXcgZXh0ZW5kcyBBYnN0cmFjdE1haW5UYWJXaXRoRGV0
YWlsc1RhYmxlVmkKICAgICAgICAgICAgIHByb3RlY3RlZCBVSUNvbW1hbmQgcmVzb2x2ZUNvbW1h
bmQoKSB7CiAgICAgICAgICAgICAgICAgcmV0dXJuIGdldE1haW5Nb2RlbCgpLmdldE5ld1NlcnZl
ckNvbW1hbmQoKTsKICAgICAgICAgICAgIH0KKworICAgICAgICAgICAgQE92ZXJyaWRlCisgICAg
ICAgICAgICBwdWJsaWMgdm9pZCBvbkNsaWNrKExpc3Q8Vk0+IHNlbGVjdGVkSXRlbXMpIHsKKyAg
ICAgICAgICAgICAgICBzdXBlci5vbkNsaWNrKHNlbGVjdGVkSXRlbXMpOworICAgICAgICAgICAg
ICAgIEFjdGlvbkJ1dHRvbkNsaWNrRXZlbnQuZmlyZShDbGllbnRHaW5qZWN0b3JQcm92aWRlci5p
bnN0YW5jZSgpLmdldEV2ZW50QnVzKCkpOworICAgICAgICAgICAgfQogICAgICAgICB9KTsKICAg
ICAgICAgZ2V0VGFibGUoKS5hZGRBY3Rpb25CdXR0b24obmV3IFdlYkFkbWluQnV0dG9uRGVmaW5p
dGlvbjxWTT4oY29uc3RhbnRzLm5ld0Rlc2t0b3BWbSgpKSB7CiAgICAgICAgICAgICBAT3ZlcnJp
ZGUKZGlmZiAtLWdpdCBhL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2ViYWRtaW4vc3JjL21h
aW4vd2ViYXBwL1dFQi1JTkYvd2ViLnhtbCBiL2Zyb250ZW5kL3dlYmFkbWluL21vZHVsZXMvd2Vi
YWRtaW4vc3JjL21haW4vd2ViYXBwL1dFQi1JTkYvd2ViLnhtbAppbmRleCBhNTBmOGFhLi42MmYw
MzEyIDEwMDY0NAotLS0gYS9mcm9udGVuZC93ZWJhZG1pbi9tb2R1bGVzL3dlYmFkbWluL3NyYy9t
YWluL3dlYmFwcC9XRUItSU5GL3dlYi54bWwKKysrIGIvZnJvbnRlbmQvd2ViYWRtaW4vbW9kdWxl
cy93ZWJhZG1pbi9zcmMvbWFpbi93ZWJhcHAvV0VCLUlORi93ZWIueG1sCkBAIC0yMyw2ICsyMywx
NiBAQAogCQk8dXJsLXBhdHRlcm4+L3dlYmFkbWluL1dlYkFkbWluLmh0bWw8L3VybC1wYXR0ZXJu
PgogCTwvc2VydmxldC1tYXBwaW5nPgogCisJPHNlcnZsZXQ+CisJCTxzZXJ2bGV0LW5hbWU+UGx1
Z2luU291cmNlUGFnZTwvc2VydmxldC1uYW1lPgorCQk8c2VydmxldC1jbGFzcz5vcmcub3ZpcnQu
ZW5naW5lLnVpLmZyb250ZW5kLnNlcnZlci5nd3QuUGx1Z2luU291cmNlUGFnZVNlcnZsZXQ8L3Nl
cnZsZXQtY2xhc3M+CisJPC9zZXJ2bGV0PgorCisJPHNlcnZsZXQtbWFwcGluZz4KKwkJPHNlcnZs
ZXQtbmFtZT5QbHVnaW5Tb3VyY2VQYWdlPC9zZXJ2bGV0LW5hbWU+CisJCTx1cmwtcGF0dGVybj4v
d2ViYWRtaW4vUGx1Z2luU291cmNlUGFnZTwvdXJsLXBhdHRlcm4+CisJPC9zZXJ2bGV0LW1hcHBp
bmc+CisKIAk8IS0tIERlZmF1bHQgcGFnZSB0byBzZXJ2ZSAtLT4KIAk8d2VsY29tZS1maWxlLWxp
c3Q+CiAJCTx3ZWxjb21lLWZpbGU+aW5kZXguaHRtbDwvd2VsY29tZS1maWxlPgotLSAKMS43LjQu
NAoK
--=_156c716f-6003-47a3-bcaa-20301ab51501--
2:10 a.m.
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).
4:40 a.m.
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
- 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"
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]
[1] - will be supported by UI plugin infrastructure
[2] - not supported by UI plugin infrastructure
Vojtech
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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).
4:54 a.m.
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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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).
5:10 a.m.
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.
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?
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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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).
5:16 a.m.
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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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).
>
>
7:26 a.m.
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).
Vojtech
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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).
>
>
7:27 a.m.
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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav
Cohen" <ecohen(a)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).
>>
>>
>
>
7:26 a.m.
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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav
Cohen" <ecohen(a)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).
>>
>>
>
>
7:42 a.m.
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" <iheim(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav
Cohen" <ecohen(a)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(a)redhat.com>
>>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav
Cohen" <ecohen(a)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).
>>>
>>>
>>
>>
>
>
8:16 a.m.
> 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" <iheim(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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" <iheim(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav
Cohen" <ecohen(a)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(a)redhat.com>
>>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav
Cohen" <ecohen(a)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).
>>>
>>>
>>
>>
>
>
8:33 a.m.
It appears to me that the cross-origin issue is caused because the plugin definition is
embedded in the WebAdmin host page that is hosted by the JBoss AS. This then requires
that all plugins also exist within the same origin. Rather than extending the WebAdmin
page with javascript, would it be possible to instead have an API that modifies that page
with extensions? For example, the API tells it to add a new menu item that when launched
would invoke the url registered with the extension. The new page is now rendered in a
distinct window (much like early versions of GWT hosted mode created an embedded browser
window).
-George
-----Original Message-----
From: engine-devel-bounces(a)ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of
Vojtech Szocs
Sent: Monday, July 23, 2012 8:27 AM
To: Itamar Heim
Cc: engine-devel
Subject: Re: [Engine-devel] oVirt UI Plugins: Update on current progress
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).
Vojtech
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
> <ecohen(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
7:58 a.m.
It appears to me that the cross-origin issue is caused because the
plugin definition is embedded in the WebAdmin host page that is hosted by the JBoss AS.
This then requires that all plugins also exist within the same origin.
Yes, WebAdmin host page is served through Engine JBoss and therefore sits on its origin.
WebAdmin host page loads a plugin by creating an iframe element and setting its
"src" attribute to HTML page that's responsible for loading the actual
plugin code. But if the plugin HTML page originates for a different origin (protocol,
domain, port), plugin code that runs within an iframe element is unable to access
top-level (WebAdmin host page) pluginApi object, because of Same-Origin-Policy
restriction.
As Itamar mentioned, we shouldn't deploy custom UI plugins on Engine JBoss, as it
would complicate its maintenance from package perspective.
There are currently two ways how plugins can be developed, and I'd like to discuss
these on the upcoming meeting:
---
1) The "Standard" way: use standard Engine servlet (PluginSourcePageServlet in
PoC) to take care of rendering plugin HTML page. This servlet will pick up all plugin
dependencies, plugin configuration and actual plugin code, and produce the resulting HTML
page used to load the plugin. Because this servlet runs on Engine JBoss, there will be no
cross-origin issues.
Pros:
- well-defined way how to develop plugins (separation of dependencies, configuration and
actual plugin code)
- no need to take care of producing HTML plugin page (servlet will take care of that)
Cons:
- doesn't support custom plugin bootstrap schemes (e.g. cannot use GWT to develop
plugins)
- due to Same-Origin-Policy, plugin can communicate with Engine (e.g. REST API), but not
with other external services (on other origins), unless you implement cross-origin
communication schemes such as JSONP
---
2) The "Custom" way: run your own application server, deploy your plugin code
there (client JavaScript code, plus optional server code). Instead of using standard
Engine servlet, use your own application server to serve plugin HTML page. This means that
you are responsible for assembling everything (plugin dependencies, configuration, code,
etc.) into HTML page used to load your plugin.
Pros:
- supports custom plugin bootstrap schemes (e.g. can use GWT to develop plugins), since
you are responsible for providing plugin HTML content
- supports hosting custom server-side plugin code (in addition to plugins being able to
call Engine through APIs like REST)
Cons:
- to work around Same-Origin-Policy (and get hold of WebAdmin's pluginApi object),
your application server needs to use CORS (Cross-Origin Resource Sharing), which basically
means extra HTTP response header
---
Originally, I wanted to start with (1) (the "Standard" way), but we should
discuss and evaluate both approaches.
Vojtech
----- Original Message -----
From: "George Costea" <George.Costea(a)netapp.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>, "Itamar Heim"
<iheim(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Monday, July 23, 2012 3:33:12 PM
Subject: RE: [Engine-devel] oVirt UI Plugins: Update on current progress
It appears to me that the cross-origin issue is caused because the plugin definition is
embedded in the WebAdmin host page that is hosted by the JBoss AS. This then requires
that all plugins also exist within the same origin. Rather than extending the WebAdmin
page with javascript, would it be possible to instead have an API that modifies that page
with extensions? For example, the API tells it to add a new menu item that when launched
would invoke the url registered with the extension. The new page is now rendered in a
distinct window (much like early versions of GWT hosted mode created an embedded browser
window).
-George
-----Original Message-----
From: engine-devel-bounces(a)ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of
Vojtech Szocs
Sent: Monday, July 23, 2012 8:27 AM
To: Itamar Heim
Cc: engine-devel
Subject: Re: [Engine-devel] oVirt UI Plugins: Update on current progress
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).
Vojtech
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
<ecohen(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Einav Cohen"
> <ecohen(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
10:25 a.m.
--_000_6C8AC8C50E170C4E9B44D47B39B24A480126A6B7SACEXCMBX04PRDh_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
SGkgVm9qdGVjaCwNCg0KSSBqdXN0IGhhZCBhIGNoYW5jZSB0byB0cnkgdGhlIHBhdGNoIHRvZGF5
IGFuZCBpdCB3b3JrcyBncmVhdC4gIFdoZW4gSSBjbGljayB0aGUg4oCcTmV3IFNlcnZlcuKAnSBi
dXR0b24gb24gdGhlIOKAnFZpcnR1YWwgTWFjaGluZXPigJ0gdGFiIEkgc2VlIHRoZSBhbGVydC4g
IFdoYXQgZG8gSSBkbyB0byBhZGQgYSBuZXcgYnV0dG9uIGJlc2lkZSBvZiB0aGUg4oCcTmV3IFNl
cnZlcuKAnSBidXR0b24gb3IgYXQgdGhlIGVuZCBhZnRlciB0aGUg4oCcR3VpZGUgTWXigJ0gYnV0
dG9uPyAgSSB3b3VsZCBsaWtlIHRvIGFkZCBteSBvd24gYnV0dG9uIHRoZXJlIGFuZCB0aGVuIGlu
dm9rZSBteSBvd24gVUkgYnVpbHQgd2l0aCBHV1QuDQoNClRoYW5rcywNCkdlb3JnZQ0KDQpGcm9t
OiBlbmdpbmUtZGV2ZWwtYm91bmNlc0BvdmlydC5vcmcgW21haWx0bzplbmdpbmUtZGV2ZWwtYm91
bmNlc0BvdmlydC5vcmddIE9uIEJlaGFsZiBPZiBWb2p0ZWNoIFN6b2NzDQpTZW50OiBGcmlkYXks
IEp1bHkgMjAsIDIwMTIgNDozOCBQTQ0KVG86IGVuZ2luZS1kZXZlbA0KU3ViamVjdDogW0VuZ2lu
ZS1kZXZlbF0gb1ZpcnQgVUkgUGx1Z2luczogVXBkYXRlIG9uIGN1cnJlbnQgcHJvZ3Jlc3MNCg0K
SGkgZ3V5cywNCg0KSSd2ZSBzcGVudCBzb21lIHRpbWUgd29ya2luZyBvbiBVSSBQbHVnaW5zIHBy
b29mLW9mLWNvbmNlcHQgKFBvQykgaW1wbGVtZW50YXRpb24sIGFuZCB0aG91Z2h0IEknZCBzaGFy
ZSBteSByZXN1bHRzIHdpdGggeW91LiBJJ3ZlIGF0dGFjaGVkIGEgcGF0Y2ggdGhhdCByZWZsZWN0
cyB0aGUgY3VycmVudCBwcm9ncmVzcy4NCg0KVGhlIGFjdHVhbCBQb0MgaW1wbGVtZW50YXRpb24g
dGFrZXMgc29tZSBpbnNwaXJhdGlvbiBmcm9tIG9WaXJ0IFVJIFBsdWdpbnMgd2lraSBwYWdlLCBh
bmQgc2ltcGxpZmllcy9zdHJlYW1saW5lcy9pbXByb3ZlcyBpdHMgbWFpbiBjb25jZXB0cy4gVGhl
IGdvYWwgaXMgdG8gaGF2ZSBzaW1wbGUtdG8tdXNlLCB5ZXQgZmxleGlibGUgYW5kIHJvYnVzdCBw
bHVnaW4gaW5mcmFzdHJ1Y3R1cmUuIE1ham9yIGNoYW5nZXMgdG8gdGhlIG9yaWdpbmFsIGRlc2ln
biBhcmUgb3V0bGluZWQgYmVsb3cuDQoNCkVhY2ggVUkgcGx1Z2luIHJ1bnMgd2l0aGluIHRoZSBj
b250ZXh0IG9mIGFuIGlmcmFtZSwgYW5kIHRoZXJlZm9yZSByZXF1aXJlcyBhIHBsdWdpbiBzb3Vy
Y2UgcGFnZSB0aGF0IGV4ZWN1dGVzIHRoZSBhY3R1YWwgcGx1Z2luIGNvZGUuDQoNCiAgKiAgIGlm
cmFtZSBpcyBlc3NlbnRpYWxseSB0aGUgc2FuZGJveCBmb3IgZWFjaCBwbHVnaW4uIFdlIGNhbiBk
aXNhYmxlIHBsdWdpbnMgYnkgZGV0YWNoaW5nIHRoZWlyIGlmcmFtZSBlbGVtZW50cyBmcm9tIHRo
ZSBtYWluIGRvY3VtZW50IGR1cmluZyBXZWJBZG1pbiBydW50aW1lLiBUaGlzIGFsc28gYWxsb3dz
IHVzIHRvIGltcGxlbWVudCBmZWF0dXJlcyBzdWNoIGFzIHBsdWdpbiBzYWZlIG1vZGUgKG5vIHBs
dWdpbnMgbG9hZGVkIG9uIFdlYkFkbWluIHN0YXJ0dXApLg0KICAqICAgUGx1Z2luIHNvdXJjZSBw
YWdlcyBhbmQgV2ViQWRtaW4gaG9zdCBwYWdlIHNoYXJlIHRoZSBzYW1lIG9yaWdpbiAocHJvdG9j
b2wsIGRvbWFpbiwgcG9ydCksIHdpdGggcGx1Z2luIHNvdXJjZSBwYWdlcyBiZWluZyBzZXJ2ZWQg
dGhyb3VnaCBFbmdpbmVNYW5hZ2VyIGFwcGxpY2F0aW9uIHNlcnZlciAoSkJvc3MgQVMpLiBUaGlz
IGlzIHRvIGF2b2lkIGNyb3NzLWRvbWFpbiB3aW5kb3cvaWZyYW1lIGNvbW11bmljYXRpb24gaXNz
dWVzLCB3aGVuIHRoZSBhY3R1YWwgcGx1Z2luIGNvZGUgcnVubmluZyBpbiBhbiBpZnJhbWUgdHJp
ZXMgdG8gcmVnaXN0ZXIgaXRzZWxmIGludG8gV2ViQWRtaW4gbWFpbiBkb2N1bWVudCdzIHBsdWdp
bkFwaSBvYmplY3QuDQogICogICBUaGVyZSdzIGEgc2VydmxldCBkZXNpZ25lZCB0byByZW5kZXIg
cGx1Z2luIHNvdXJjZSBwYWdlIGZvciBhbGwgcGx1Z2lucyAoUGx1Z2luU291cmNlUGFnZVNlcnZs
ZXQpLiBGb3IgdGhlIGdpdmVuIHBsdWdpbiwgaXQgZGV0ZWN0cyBpdHMgZGVwZW5kZW5jaWVzICgz
cmQgcGFydHkgSmF2YVNjcmlwdCBsaWJyYXJpZXMpIGFuZCBjb25maWd1cmF0aW9uIG9iamVjdCAo
SlNPTiBkYXRhKSwgcmVhZHMgdGhlIGFjdHVhbCBwbHVnaW4gY29kZSwgYW5kIGFzc2VtYmxlcyBl
dmVyeXRoaW5nIGludG8gdGhlIHJlc3VsdGluZyBIVE1MIHBhZ2UgKHRvIGJlIGV2YWx1YXRlZCBi
eSB0aGUgcGx1Z2luIGlmcmFtZSkuDQogICogICBpZnJhbWUgaXNvbGF0ZXMgcGx1Z2luIGRlcGVu
ZGVuY2llcyAoM3JkIHBhcnR5IEphdmFTY3JpcHQgbGlicmFyaWVzKSBmcm9tIG90aGVyIHBsdWdp
bnMgYW5kIHRoZSBtYWluIFdlYkFkbWluIGRvY3VtZW50LiBJbiBwcmFjdGljZSwgdGhpcyBtZWFu
cyB0aGF0IHBsdWdpbiBBIGNhbiB1c2UgalF1ZXJ5IDEuNyBhbmQgcGx1Z2luIEIgY2FuIHVzZSBq
UXVlcnkgMS42IHdpdGhvdXQgdGhlIGZlYXIgb2YgYW55IGNsYXNoZXMuDQogICogICBMYXN0IGJ1
dCBub3QgbGVhc3QsIHdyaXRpbmcgcGx1Z2lucyBpbiBHb29nbGUgV2ViIFRvb2xraXQgKEdXVCkg
c2hvdWxkIGJlIGFzIGVhc3kgYXMgcHJvdmlkaW5nIHlvdXIgb3duIHBsdWdpbiBzb3VyY2UgcGFn
ZS4gSnVzdCBkZXBsb3kgeW91ciBHV1QgcGx1Z2luIGFwcGxpY2F0aW9uIG9uIEpCb3NzIEFTIChu
ZXh0IHRvIGVuZ2luZS5lYXIpLCBhbmQgcG9pbnQgdG8gR1dUIHBsdWdpbiBhcHBsaWNhdGlvbiBo
b3N0IHBhZ2UuDQoNClRoZSBjdXJyZW50IFBvQyBkZWNsYXJlcyBhIHNpbXBsZSBwbHVnaW4gdGhh
dCBnZXRzIGxvYWRlZCB1c2luZyBoYXJkLWNvZGVkIHZhbHVlcyBpbiBQbHVnaW5Tb3VyY2VQYWdl
U2VydmxldC4gQWN0dWFsIHBsdWdpbiBjb2RlIHJlZ2lzdGVycyB0aGUgcGx1Z2luIGludG8gZ2xv
YmFsIHBsdWdpbkFwaS5wbHVnaW5zIG9iamVjdCwgd2l0aCBvbmUgc2FtcGxlIGV2ZW50IGhhbmRs
ZXIgZnVuY3Rpb24gKEFjdGlvbkJ1dHRvbkNsaWNrKS4gSnVzdCBhZnRlciB0aGF0LCB0aGUgcGx1
Z2luIHJlcG9ydHMgaW4gYXMgcmVhZHkgYnkgY2FsbGluZyBwbHVnaW5BcGkucmVhZHkgZnVuY3Rp
b24uIFRoaXMgZXNzZW50aWFsbHkgcHV0cyB0aGUgcGx1Z2luIGludG8gdXNlIHdpdGhpbiBXZWJB
ZG1pbi4NCg0KDQpUbyBzaW11bGF0ZSBleHRlbnNpb24gcG9pbnQgKGFwcGxpY2F0aW9uIGV2ZW50
IHRvIGJlIGNvbnN1bWVkIGJ5IHBsdWdpbnMpLCB3aGVuIHRoZSB1c2VyIGNsaWNrcyAiTmV3IHNl
cnZlciIgYnV0dG9uIG9uICJWaXJ0dWFsIE1hY2hpbmVzIiBtYWluIHRhYiwgQWN0aW9uQnV0dG9u
Q2xpY2tFdmVudCBnZXRzIGZpcmVkIHRocm91Z2ggV2ViQWRtaW4gZXZlbnQgYnVzLiBQbHVnaW5F
dmVudEhhbmRsZXIgcmVjZWl2ZXMgdGhpcyBldmVudCBhbmQgaW52b2tlcyBBY3Rpb25CdXR0b25D
bGljayBldmVudCBoYW5kbGVyIGZ1bmN0aW9uIG9uIGFsbCBwbHVnaW5zLg0KDQoNCg0KKE5vdGU6
IGZvciBwYXNzaW5nIGNvbnRleHQgb2JqZWN0cyBmcm9tIFdlYkFkbWluIHRvIHBsdWdpbiBldmVu
dCBoYW5kbGVyIGZ1bmN0aW9ucywgSSdtIHBsYW5uaW5nIHRvIGV4cGVyaW1lbnQgd2l0aCBnd3Qt
ZXhwb3J0ZXIgcHJvamVjdCBbMV0uIFRoaXMgd291bGQgZ3JlYXRseSBzaW1wbGlmeSB0aGUgd2F5
IGhvdyBXZWJBZG1pbiBleHBvc2VzIGNvbnRleHQtc3BlY2lmaWMgcGx1Z2luIEFQSSB0byBldmVu
dCBoYW5kbGVyIGZ1bmN0aW9ucy4pDQoNCg0KDQpBcyBmb3IgdGhlIG5leHQgc3RlcCwgSSBzdWdn
ZXN0IHRvIGhhdmUgc29tZSBtZWV0aW5nIChjb25mZXJlbmNlKSB0byBkaXNjdXNzIHRoZSBQb0Mg
aW4gZGV0YWlsLCBhbmQgb3V0bGluZSB0YXNrcyBmb3IgdGhlIG5lYXIgZnV0dXJlLiBBbHNvLCBw
bGVhc2UgbGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsgb2YgdGhlIFBvQyBzbyBmYXIuDQoNCkNo
ZWVycywNClZvanRlY2gNCg0KWzFdIGh0dHA6Ly9jb2RlLmdvb2dsZS5jb20vcC9nd3QtZXhwb3J0
ZXIvDQoNCg0K
--_000_6C8AC8C50E170C4E9B44D47B39B24A480126A6B7SACEXCMBX04PRDh_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg
MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl
LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv
Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt
ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l
O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u
bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp
biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj
dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp
c3QgbDANCgl7bXNvLWxpc3QtaWQ6NTk5MDU2MjE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi05
MDY3NTI1OTA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1
bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJ
bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt
c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs
MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10
ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z
aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv
cDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww
OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s
ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz
LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz
O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl
dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0
aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N
CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K
PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91
dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz
aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT
IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SGkgVm9qdGVjaCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkganVzdCBoYWQgYSBjaGFuY2UgdG8gdHJ5
IHRoZSBwYXRjaCB0b2RheSBhbmQgaXQgd29ya3MgZ3JlYXQuJm5ic3A7IFdoZW4gSSBjbGljayB0
aGUg4oCcTmV3IFNlcnZlcuKAnSBidXR0b24gb24gdGhlIOKAnFZpcnR1YWwgTWFjaGluZXPigJ0g
dGFiIEkgc2VlIHRoZSBhbGVydC4mbmJzcDsgV2hhdCBkbw0KIEkgZG8gdG8gYWRkIGEgbmV3IGJ1
dHRvbiBiZXNpZGUgb2YgdGhlIOKAnE5ldyBTZXJ2ZXLigJ0gYnV0dG9uIG9yIGF0IHRoZSBlbmQg
YWZ0ZXIgdGhlIOKAnEd1aWRlIE1l4oCdIGJ1dHRvbj8mbmJzcDsgSSB3b3VsZCBsaWtlIHRvIGFk
ZCBteSBvd24gYnV0dG9uIHRoZXJlIGFuZCB0aGVuIGludm9rZSBteSBvd24gVUkgYnVpbHQgd2l0
aCBHV1QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdl
b3JnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9
Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg
MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGVu
Z2luZS1kZXZlbC1ib3VuY2VzQG92aXJ0Lm9yZyBbbWFpbHRvOmVuZ2luZS1kZXZlbC1ib3VuY2Vz
QG92aXJ0Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Vm9qdGVjaCBTem9jczxicj4NCjxiPlNl
bnQ6PC9iPiBGcmlkYXksIEp1bHkgMjAsIDIwMTIgNDozOCBQTTxicj4NCjxiPlRvOjwvYj4gZW5n
aW5lLWRldmVsPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFbmdpbmUtZGV2ZWxdIG9WaXJ0IFVJIFBs
dWdpbnM6IFVwZGF0ZSBvbiBjdXJyZW50IHByb2dyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+
SGkgZ3V5cyw8YnI+DQo8YnI+DQpJJ3ZlIHNwZW50IHNvbWUgdGltZSB3b3JraW5nIG9uIFVJIFBs
dWdpbnMgcHJvb2Ytb2YtY29uY2VwdCAoUG9DKSBpbXBsZW1lbnRhdGlvbiwgYW5kIHRob3VnaHQg
SSdkIHNoYXJlIG15IHJlc3VsdHMgd2l0aCB5b3UuIEkndmUgYXR0YWNoZWQgYSBwYXRjaCB0aGF0
IHJlZmxlY3RzIHRoZSBjdXJyZW50IHByb2dyZXNzLg0KPGJyPg0KPGJyPg0KVGhlIGFjdHVhbCBQ
b0MgaW1wbGVtZW50YXRpb24gdGFrZXMgc29tZSBpbnNwaXJhdGlvbiBmcm9tIG9WaXJ0IFVJIFBs
dWdpbnMgd2lraSBwYWdlLCBhbmQgc2ltcGxpZmllcy9zdHJlYW1saW5lcy9pbXByb3ZlcyBpdHMg
bWFpbiBjb25jZXB0cy4gVGhlIGdvYWwgaXMgdG8gaGF2ZSBzaW1wbGUtdG8tdXNlLCB5ZXQgZmxl
eGlibGUgYW5kIHJvYnVzdCBwbHVnaW4gaW5mcmFzdHJ1Y3R1cmUuIE1ham9yIGNoYW5nZXMgdG8g
dGhlIG9yaWdpbmFsIGRlc2lnbg0KIGFyZSBvdXRsaW5lZCBiZWxvdy48YnI+DQo8YnI+DQo8c3Ry
b25nPkVhY2ggVUkgcGx1Z2luIHJ1bnMgd2l0aGluIHRoZSBjb250ZXh0IG9mIGFuIGlmcmFtZSwg
YW5kIHRoZXJlZm9yZSByZXF1aXJlcyBhDQo8L3N0cm9uZz48Yj48aT5wbHVnaW4gc291cmNlIHBh
Z2U8L2k+IHRoYXQgZXhlY3V0ZXMgdGhlIGFjdHVhbCBwbHVnaW4gY29kZS48L2I+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQppZnJhbWUgaXMgZXNzZW50aWFs
bHkgdGhlIHNhbmRib3ggZm9yIGVhY2ggcGx1Z2luLiBXZSBjYW4gZGlzYWJsZSBwbHVnaW5zIGJ5
IGRldGFjaGluZyB0aGVpciBpZnJhbWUgZWxlbWVudHMgZnJvbSB0aGUgbWFpbiBkb2N1bWVudCBk
dXJpbmcgV2ViQWRtaW4gcnVudGltZS4gVGhpcyBhbHNvIGFsbG93cyB1cyB0byBpbXBsZW1lbnQg
ZmVhdHVyZXMgc3VjaCBhcw0KPGVtPnBsdWdpbiBzYWZlIG1vZGU8L2VtPiAobm8gcGx1Z2lucyBs
b2FkZWQgb24gV2ViQWRtaW4gc3RhcnR1cCkuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KUGx1Z2luIHNv
dXJjZSBwYWdlcyBhbmQgV2ViQWRtaW4gaG9zdCBwYWdlIHNoYXJlIHRoZSBzYW1lIG9yaWdpbiAo
cHJvdG9jb2wsIGRvbWFpbiwgcG9ydCksIHdpdGggcGx1Z2luIHNvdXJjZSBwYWdlcyBiZWluZyBz
ZXJ2ZWQgdGhyb3VnaCBFbmdpbmVNYW5hZ2VyIGFwcGxpY2F0aW9uIHNlcnZlciAoSkJvc3MgQVMp
LiBUaGlzIGlzIHRvIGF2b2lkIGNyb3NzLWRvbWFpbiB3aW5kb3cvaWZyYW1lIGNvbW11bmljYXRp
b24gaXNzdWVzLCB3aGVuIHRoZQ0KIGFjdHVhbCBwbHVnaW4gY29kZSBydW5uaW5nIGluIGFuIGlm
cmFtZSB0cmllcyB0byByZWdpc3RlciBpdHNlbGYgaW50byBXZWJBZG1pbiBtYWluIGRvY3VtZW50
J3MNCjxpPnBsdWdpbkFwaTwvaT4gb2JqZWN0LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZXJlJ3Mg
YSBzZXJ2bGV0IGRlc2lnbmVkIHRvIHJlbmRlciBwbHVnaW4gc291cmNlIHBhZ2UgZm9yIGFsbCBw
bHVnaW5zICg8aT5QbHVnaW5Tb3VyY2VQYWdlU2VydmxldDwvaT4pLiBGb3IgdGhlIGdpdmVuIHBs
dWdpbiwgaXQgZGV0ZWN0cyBpdHMgZGVwZW5kZW5jaWVzICgzcmQgcGFydHkgSmF2YVNjcmlwdCBs
aWJyYXJpZXMpIGFuZCBjb25maWd1cmF0aW9uIG9iamVjdCAoSlNPTiBkYXRhKSwgcmVhZHMgdGhl
IGFjdHVhbCBwbHVnaW4gY29kZSwNCiBhbmQgYXNzZW1ibGVzIGV2ZXJ5dGhpbmcgaW50byB0aGUg
cmVzdWx0aW5nIEhUTUwgcGFnZSAodG8gYmUgZXZhbHVhdGVkIGJ5IHRoZSBwbHVnaW4gaWZyYW1l
KS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFj
azttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t
bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQppZnJhbWUgaXNvbGF0ZXMgcGx1Z2luIGRlcGVuZGVuY2ll
cyAoM3JkIHBhcnR5IEphdmFTY3JpcHQgbGlicmFyaWVzKSBmcm9tIG90aGVyIHBsdWdpbnMgYW5k
IHRoZSBtYWluIFdlYkFkbWluIGRvY3VtZW50LiBJbiBwcmFjdGljZSwgdGhpcyBtZWFucyB0aGF0
IHBsdWdpbiBBIGNhbiB1c2UgalF1ZXJ5IDEuNyBhbmQgcGx1Z2luIEIgY2FuIHVzZSBqUXVlcnkg
MS42IHdpdGhvdXQgdGhlIGZlYXIgb2YgYW55IGNsYXNoZXMuPG86cD48L286cD48L2xpPjxsaSBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0K
TGFzdCBidXQgbm90IGxlYXN0LCB3cml0aW5nIHBsdWdpbnMgaW4gR29vZ2xlIFdlYiBUb29sa2l0
IChHV1QpIHNob3VsZCBiZSBhcyBlYXN5IGFzIHByb3ZpZGluZyB5b3VyIG93biBwbHVnaW4gc291
cmNlIHBhZ2UuIEp1c3QgZGVwbG95IHlvdXIgR1dUIHBsdWdpbiBhcHBsaWNhdGlvbiBvbiBKQm9z
cyBBUyAobmV4dCB0bw0KPGk+ZW5naW5lLmVhcjwvaT4pLCBhbmQgcG9pbnQgdG8gR1dUIHBsdWdp
biBhcHBsaWNhdGlvbiBob3N0IHBhZ2UuPG86cD48L286cD48L2xpPjwvdWw+DQo8cD48c3BhbiBz
dHlsZT0iY29sb3I6YmxhY2siPlRoZSBjdXJyZW50IFBvQyBkZWNsYXJlcyBhIHNpbXBsZSBwbHVn
aW4gdGhhdCBnZXRzIGxvYWRlZCB1c2luZyBoYXJkLWNvZGVkIHZhbHVlcyBpbg0KPGk+UGx1Z2lu
U291cmNlUGFnZVNlcnZsZXQ8L2k+LiBBY3R1YWwgcGx1Z2luIGNvZGUgcmVnaXN0ZXJzIHRoZSBw
bHVnaW4gaW50byBnbG9iYWwNCjxpPnBsdWdpbkFwaS5wbHVnaW5zPC9pPiBvYmplY3QsIHdpdGgg
b25lIHNhbXBsZSBldmVudCBoYW5kbGVyIGZ1bmN0aW9uICg8aT5BY3Rpb25CdXR0b25DbGljazwv
aT4pLiBKdXN0IGFmdGVyIHRoYXQsIHRoZSBwbHVnaW4gcmVwb3J0cyBpbiBhcyByZWFkeSBieSBj
YWxsaW5nDQo8aT5wbHVnaW5BcGkucmVhZHk8L2k+IGZ1bmN0aW9uLiBUaGlzIGVzc2VudGlhbGx5
IHB1dHMgdGhlIHBsdWdpbiBpbnRvIHVzZSB3aXRoaW4gV2ViQWRtaW4uPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
PlRvIHNpbXVsYXRlIGV4dGVuc2lvbiBwb2ludCAoYXBwbGljYXRpb24gZXZlbnQgdG8gYmUgY29u
c3VtZWQgYnkgcGx1Z2lucyksIHdoZW4gdGhlIHVzZXIgY2xpY2tzICZxdW90O05ldyBzZXJ2ZXIm
cXVvdDsgYnV0dG9uIG9uICZxdW90O1ZpcnR1YWwgTWFjaGluZXMmcXVvdDsgbWFpbiB0YWIsDQo8
aT5BY3Rpb25CdXR0b25DbGlja0V2ZW50PC9pPiBnZXRzIGZpcmVkIHRocm91Z2ggV2ViQWRtaW4g
ZXZlbnQgYnVzLiA8aT5QbHVnaW5FdmVudEhhbmRsZXI8L2k+IHJlY2VpdmVzIHRoaXMgZXZlbnQg
YW5kIGludm9rZXMNCjxpPkFjdGlvbkJ1dHRvbkNsaWNrPC9pPiBldmVudCBoYW5kbGVyIGZ1bmN0
aW9uIG9uIGFsbCBwbHVnaW5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxl
PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5
bGU9ImNvbG9yOmJsYWNrIj4oTm90ZTogZm9yIHBhc3NpbmcgY29udGV4dCBvYmplY3RzIGZyb20g
V2ViQWRtaW4gdG8gcGx1Z2luIGV2ZW50IGhhbmRsZXIgZnVuY3Rpb25zLCBJJ20gcGxhbm5pbmcg
dG8gZXhwZXJpbWVudCB3aXRoIGd3dC1leHBvcnRlciBwcm9qZWN0IFsxXS4gVGhpcyB3b3VsZCBn
cmVhdGx5IHNpbXBsaWZ5IHRoZSB3YXkgaG93IFdlYkFkbWluIGV4cG9zZXMgY29udGV4dC1zcGVj
aWZpYyBwbHVnaW4gQVBJIHRvDQogZXZlbnQgaGFuZGxlciBmdW5jdGlvbnMuKTxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BcyBmb3IgdGhlIG5l
eHQgc3RlcCwgSSBzdWdnZXN0IHRvIGhhdmUgc29tZSBtZWV0aW5nIChjb25mZXJlbmNlKSB0byBk
aXNjdXNzIHRoZSBQb0MgaW4gZGV0YWlsLCBhbmQgb3V0bGluZSB0YXNrcyBmb3IgdGhlIG5lYXIg
ZnV0dXJlLiBBbHNvLCBwbGVhc2UgbGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbmsgb2YgdGhlIFBv
QyBzbyBmYXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQpDaGVlcnMsPGJyPg0KVm9qdGVjaDxicj4NCjxi
cj4NClsxXSA8YSBocmVmPSJodHRwOi8vY29kZS5nb29nbGUuY29tL3AvZ3d0LWV4cG9ydGVyLyI+
aHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9wL2d3dC1leHBvcnRlci88L2E+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K
--_000_6C8AC8C50E170C4E9B44D47B39B24A480126A6B7SACEXCMBX04PRDh_--
8:12 a.m.
Hi George,
the PoC defines a simple ActionButtonClick event which is fired when the user clicks on
"New Server" button, and WebAdmin invokes ActionButtonClick function on all
plugins. This is just an example to demonstrate how plugin invocation could work.
If you want to add new button to VM main tab, there should be a separate event fired when
the VM main tab is rendered, with plugins providing extra button definitions.
Alternatively, pluginApi object can provide some API to add these buttons at time when
plugin code gets loaded. Unfortunately, this isn't part of the PoC yet, as I wanted to
discuss this with you before continuing with PoC implementation.
As for developing plugins with GWT, I've sent a mail about this, discussing two
possible ways to develop plugins. We should evaluate pros/cons of each approach and decide
which way to go first.. (the PoC contains hand-written JavaScript for now though)
Vojtech
----- Original Message -----
From: "George Costea" <George.Costea(a)netapp.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Wednesday, July 25, 2012 5:25:17 PM
Subject: RE: [Engine-devel] oVirt UI Plugins: Update on current progress
Hi Vojtech,
I just had a chance to try the patch today and it works great. When I click the “New
Server” button on the “Virtual Machines” tab I see the alert. What do I do to add a new
button beside of the “New Server” button or at the end after the “Guide Me” button? I
would like to add my own button there and then invoke my own UI built with GWT.
Thanks,
George
From: engine-devel-bounces(a)ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of
Vojtech Szocs
Sent: Friday, July 20, 2012 4:38 PM
To: engine-devel
Subject: [Engine-devel] oVirt UI Plugins: Update on current progress
Hi guys,
I've spent some time working on UI Plugins proof-of-concept (PoC) implementation, and
thought I'd share my results with you. I've attached a patch that reflects the
current progress.
The actual PoC implementation takes some inspiration from oVirt UI Plugins wiki page, and
simplifies/streamlines/improves its main concepts. The goal is to have simple-to-use, yet
flexible and robust plugin infrastructure. Major changes to the original design are
outlined below.
Each UI plugin runs within the context of an iframe, and therefore requires a plugin
source page that executes the actual plugin code.
* iframe is essentially the sandbox for each plugin. We can disable plugins by
detaching their iframe elements from the main document during WebAdmin runtime. This also
allows us to implement features such as plugin safe mode (no plugins loaded on WebAdmin
startup).
* Plugin source pages and WebAdmin host page share the same origin (protocol, domain,
port), with plugin source pages being served through EngineManager application server
(JBoss AS). This is to avoid cross-domain window/iframe communication issues, when the
actual plugin code running in an iframe tries to register itself into WebAdmin main
document's pluginApi object.
* There's a servlet designed to render plugin source page for all plugins (
PluginSourcePageServlet ). For the given plugin, it detects its dependencies (3rd party
JavaScript libraries) and configuration object (JSON data), reads the actual plugin code,
and assembles everything into the resulting HTML page (to be evaluated by the plugin
iframe).
* iframe isolates plugin dependencies (3rd party JavaScript libraries) from other
plugins and the main WebAdmin document. In practice, this means that plugin A can use
jQuery 1.7 and plugin B can use jQuery 1.6 without the fear of any clashes.
* 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.
The current PoC declares a simple plugin that gets loaded using hard-coded values in
PluginSourcePageServlet . Actual plugin code registers the plugin into global
pluginApi.plugins object, with one sample event handler function ( ActionButtonClick ).
Just after that, the plugin reports in as ready by calling pluginApi.ready function. This
essentially puts the plugin into use within WebAdmin.
To simulate extension point (application event to be consumed by plugins), when the user
clicks "New server" button on "Virtual Machines" main tab,
ActionButtonClickEvent gets fired through WebAdmin event bus. PluginEventHandler receives
this event and invokes ActionButtonClick event handler function on all plugins.
(Note: for passing context objects from WebAdmin to plugin event handler functions,
I'm planning to experiment with gwt-exporter project [1]. This would greatly simplify
the way how WebAdmin exposes context-specific plugin API to event handler functions.)
As for the next step, I suggest to have some meeting (conference) to discuss the PoC in
detail, and outline tasks for the near future. Also, please let me know what you think of
the PoC so far.
Cheers,
Vojtech
[1] http://code.google.com/p/gwt-exporter/
4531
days inactive
4538
days old
14 comments
3 participants
participants (3)
-
Costea, George -
Itamar Heim -
Vojtech Szocs