[ovirt-devel] removed some marked fields from instance type
Hi all, as you may know, a subpart of the instance type entity (the marked column from [1]) are the ones which are marked with the chain icon in the VM dialogs. The meaning is that this fields are so important that if you want the newly created VM to be based on that instance type, you can not change any of this fields. The problem was that too many of the fields was marked which would force the user to create lots of instance types like: big with soundcard, big with smardcard and soundcard, medium with smardcard and without soundcard etc. This after some more thinking seems to be an incorrect approach - the list of marked fields should be small and contain only the really most important fields which lets you to categorize the VMs and not all the devices. I have proposed two patches ([2], [3]) which implement this. According to this patches only the following fields will be marked: - memory size - num of sockets/cores per socket - HA - migration model/downtime - priority - balloon - min allocated memory So the behavior will now be: - the instance type still contains all kinds of devices we support - only a small part of them are marked - when the user creates a VM from an instance type, he will be provided by a big set of defaults from the instance type he can tune - he will also be provided by a small set of fields he can not change if does not want to be detached from the instance type Thoughts? Tomas [1]: http://www.ovirt.org/Features/Instance_Types#Design [2]: http://gerrit.ovirt.org/#/c/34915/ [3]: http://gerrit.ovirt.org/#/c/34916/ ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Alon Bar-Lev alo...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com
Sent: Wednesday, November 5, 2014 5:16:15 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Vojtech Szocs vsz...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com
Sent: Wednesday, November 5, 2014 6:07:50 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Alon Bar-Lev alo...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com
Sent: Wednesday, November 5, 2014 4:32:31 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Vojtech Szocs vsz...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com
Sent: Wednesday, November 5, 2014 5:24:14 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Alon Bar-Lev alo...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com
Sent: Wednesday, November 5, 2014 4:12:06 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Vojtech Szocs vsz...@redhat.com
To: devel@ovirt.org
Cc: Mark Proctor mdproc...@gmail.com
Sent: Wednesday, November 5, 2014 5:04:24 PM
Subject: [ovirt-devel] Thoughts on modularization
Hi guys,
I've discussed this recently with Yair and Mark, I just wanted to
share
some more thoughts on this topic -- in particular, how
modularization
problem can be approached (regardless of implementation details).
I see two approaches here. The typical one is to define APIs for
modules
to consume. For example, oVirt Engine extension API has API for
auth
stuff; oVirt UI plugin API has API for showing tabs and dialogs,
etc.
The advantage is strict consistency, disadvantage is burden of
having
to maintain the whole API. With this approach, you tell modules:
This
is the API to work with system, defining how you can plug into it.
Now turn 180 degrees. The other approach, which is really
interesting,
is to let modules themselves export API. This naturally leads to
module
hierarchies. Ultimately, this leads to micro-kernel-style
development,
where all logic resides in modules. Now you might ask: What if we
want
to employ some consistent work flow across multiple modules? For
example,
have some pluggable *auth* infra? -- this can be done via some
higher
level module, that exports API and lower level modules consume
that
API.
If you have any ideas, please share!
Both solutions can be applied using existing extension api, an
extension
can
locate other extension and interact with it the same way the core
interacts
with extensions.
But how does core interact with extensions? I assume via well-defined
API, i.e. in accordance with first approach mentioned above.
presentation:
http://www.ovirt.org/File:Ovirt_3.5_-_aaa.pdf
Thanks for sharing!
package org.ovirt.engine.api.extensions;
/**
* Interface of an extension.
*/
public interface Extension {
/**
* Invoke operation.
* @param input input parameters.
* @param output output parameters.
*
* p
* Interaction is done via the parameters.
* Exceptions are not allowed.
* /p
* p
* Basic mappings available at {@link Base}.
* /p
*
* @see Base
*/
void invoke(ExtMap input, ExtMap output);
}
OK, so it was my lack of knowledge of AAA implementation :)
Since Extension interface is invoke-based, I assume that Engine
core (backend) invokes extensions on specific occasions, right?
correct, and nothing prevents extension to invoke other extensions.
I see. I just wanted to clarify who makes the initial invocation.
If there is some core, extensions just extend that core. This is
different from my view of pure modularization, where there is no
core, there are just modules and all important logic resides in
modules.
With second approach mentioned above, core would not interact with
extensions at all (or in a very limited way), instead - extensions
would interact with each other. In other words, extension would not
need to implement core-specific API (there would be none), instead
it would inject its dependencies (other modules/extensions) and
Re: [ovirt-devel] Thoughts on modularization
- Original Message - From: Sven Kieske s.kie...@mittwald.de To: devel@ovirt.org Sent: Wednesday, November 5, 2014 5:36:39 PM Subject: Re: [ovirt-devel] Thoughts on modularization On 05/11/14 17:07, Vojtech Szocs wrote: This way, you'd have one core module, providing most general functionality/abstractions. Then you'd have more specific modules, plugged into core module's API etc. In other words, hierarchy of modules. This is essentially modularization taken to extreme :) Welcome to dependency hell or circular dependencies etc. Just because the problem of circular dependencies exists, doesn't mean we shouldn't try to build systems utilizing dependencies. It can be solved/addressed. Division by zero is a known problem in integral arithmetic, but it doesn't prevent calculator manufacturers from producing simple calculators, right? would you like to code your own dependency resolver? No, I'd like to use what's already available. http://requirejs.org/ http://www.2ality.com/2014/09/es6-modules-final.html I like modularization, but you can overengineer everything. I don't consider modular architecture as over-engineering. If we define modules on reasonable level of granularity, the end result might be better than one big monolithic GWT application. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Thoughts on modularization
- Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Sven Kieske s.kie...@mittwald.de Cc: devel@ovirt.org Sent: Wednesday, November 5, 2014 9:34:20 PM Subject: Re: [ovirt-devel] Thoughts on modularization - Original Message - From: Sven Kieske s.kie...@mittwald.de To: devel@ovirt.org Sent: Wednesday, November 5, 2014 6:36:39 PM Subject: Re: [ovirt-devel] Thoughts on modularization On 05/11/14 17:07, Vojtech Szocs wrote: This way, you'd have one core module, providing most general functionality/abstractions. Then you'd have more specific modules, plugged into core module's API etc. In other words, hierarchy of modules. This is essentially modularization taken to extreme :) Welcome to dependency hell or circular dependencies etc. would you like to code your own dependency resolver? I assume dependency resolving can be based on Topological sorting of Graph theory. I assume the extensions that will participate as nodes in the graph will be those who are enabled in their configuration Exactly :) I like modularization, but you can overengineer everything. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Yair Zaslavsky yzasl...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: Vojtech Szocs vsz...@redhat.com, Mark Proctor
mdproc...@gmail.com, devel@ovirt.org
Sent: Wednesday, November 5, 2014 9:40:05 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Alon Bar-Lev alo...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: Mark Proctor mdproc...@gmail.com, devel@ovirt.org
Sent: Wednesday, November 5, 2014 6:16:15 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Vojtech Szocs vsz...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com
Sent: Wednesday, November 5, 2014 6:07:50 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Alon Bar-Lev alo...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com
Sent: Wednesday, November 5, 2014 4:32:31 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Vojtech Szocs vsz...@redhat.com
To: Alon Bar-Lev alo...@redhat.com
Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com
Sent: Wednesday, November 5, 2014 5:24:14 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Alon Bar-Lev alo...@redhat.com
To: Vojtech Szocs vsz...@redhat.com
Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com
Sent: Wednesday, November 5, 2014 4:12:06 PM
Subject: Re: [ovirt-devel] Thoughts on modularization
- Original Message -
From: Vojtech Szocs vsz...@redhat.com
To: devel@ovirt.org
Cc: Mark Proctor mdproc...@gmail.com
Sent: Wednesday, November 5, 2014 5:04:24 PM
Subject: [ovirt-devel] Thoughts on modularization
Hi guys,
I've discussed this recently with Yair and Mark, I just wanted to
share
some more thoughts on this topic -- in particular, how
modularization
problem can be approached (regardless of implementation details).
I see two approaches here. The typical one is to define APIs for
modules
to consume. For example, oVirt Engine extension API has API for
auth
stuff; oVirt UI plugin API has API for showing tabs and dialogs,
etc.
The advantage is strict consistency, disadvantage is burden of
having
to maintain the whole API. With this approach, you tell modules:
This
is the API to work with system, defining how you can plug into
it.
Now turn 180 degrees. The other approach, which is really
interesting,
is to let modules themselves export API. This naturally leads to
module
hierarchies. Ultimately, this leads to micro-kernel-style
development,
where all logic resides in modules. Now you might ask: What if
we
want
to employ some consistent work flow across multiple modules? For
example,
have some pluggable *auth* infra? -- this can be done via some
higher
level module, that exports API and lower level modules consume
that
API.
If you have any ideas, please share!
Both solutions can be applied using existing extension api, an
extension
can
locate other extension and interact with it the same way the core
interacts
with extensions.
But how does core interact with extensions? I assume via well-defined
API, i.e. in accordance with first approach mentioned above.
presentation:
http://www.ovirt.org/File:Ovirt_3.5_-_aaa.pdf
Thanks for sharing!
package org.ovirt.engine.api.extensions;
/**
* Interface of an extension.
*/
public interface Extension {
/**
* Invoke operation.
* @param input input parameters.
* @param output output parameters.
*
* p
* Interaction is done via the parameters.
* Exceptions are not allowed.
* /p
* p
* Basic mappings available at {@link Base}.
* /p
*
* @see Base
*/
void invoke(ExtMap input, ExtMap output);
}
OK, so it was my lack of knowledge of AAA implementation :)
Since Extension interface is invoke-based, I assume that Engine
core (backend) invokes extensions on specific occasions, right?
correct, and nothing prevents extension to invoke other extensions.
With second approach mentioned above, core would not interact with
extensions at all (or in a very limited way), instead - extensions
would interact with each
[ovirt-devel] Error building engine on FC21
[INFO] [INFO] Building builtin-extensions 3.5.1-SNAPSHOT [INFO] [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ builtin --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 0 resource [INFO] Copying 4 resources [INFO] [INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ builtin --- [INFO] Compiling 167 source files to /root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/target/classes [INFO] - [WARNING] COMPILATION WARNING : [INFO] - [WARNING] /root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[19,24] LdapCtxFactory is internal proprietary API and may be removed in a future release [WARNING] /root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[19,24] LdapCtxFactory is internal proprietary API and may be removed in a future release [WARNING] /root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[19,24] LdapCtxFactory is internal proprietary API and may be removed in a future release [WARNING] class file for org.springframework.beans.factory.InitializingBean not found /root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[68,40] LdapCtxFactory is internal proprietary API and may be removed in a future release [INFO] 4 warnings [INFO] - [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] /root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[64,26] error: cannot access InitializingBean [ERROR] /root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[145,31] error: cannot access DisposableBean [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 01:34 min [INFO] Finished at: 2014-11-07T16:05:23+01:00 [INFO] Final Memory: 174M/873M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project builtin: Compilation failure: Compilation failure: [ERROR] /root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[64,26] error: cannot access InitializingBean [ERROR] /root/rpmbuild/BUILD/ovirt-engine-3.5.1/backend/manager/modules/builtin-extensions/src/main/java/org/ovirt/engine/extensions/aaa/builtin/kerberosldap/LDAPTemplateWrapper.java:[145,31] error: cannot access DisposableBean -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Thoughts on modularization
Hi, I can summarized that you want again to go into the Java way and not the Simple/primitive way. I think it is a mistake and will not have any benefit, API can be a wrapper over primitive interaction. We were there at past discussions, and as there is no leader of project we can discuss this to death, and I am not intend to do this yet another time (we have done this at branding, we have done this for aaa, partially for ui plugins [there we should kill gwt], and ...). I will make this short... 1. the current extension api is sufficient to construct a very complex implementation using very simple and primitive interface. 2. the current extension api enable implementing extensions using non java technologies, such as javascript/jpython. 3. the current extension api enable to not have any difference if core or extension interacts with extensions. 4. the current extension api enable forward and backward compatibility in simple methodology,. 5. a wrapper over the extension api can provide whatever high level api that is preferred by developer as an optional utility. we can always over engineer solution or have java specific solutions, I always vote for simplicity. Alon - Original Message - From: Vojtech Szocs vsz...@redhat.com To: Yair Zaslavsky yzasl...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, Mark Proctor mdproc...@gmail.com, devel@ovirt.org Sent: Friday, November 7, 2014 4:53:49 PM Subject: Re: [ovirt-devel] Thoughts on modularization - Original Message - From: Yair Zaslavsky yzasl...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Vojtech Szocs vsz...@redhat.com, Mark Proctor mdproc...@gmail.com, devel@ovirt.org Sent: Wednesday, November 5, 2014 9:40:05 PM Subject: Re: [ovirt-devel] Thoughts on modularization - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: Mark Proctor mdproc...@gmail.com, devel@ovirt.org Sent: Wednesday, November 5, 2014 6:16:15 PM Subject: Re: [ovirt-devel] Thoughts on modularization - Original Message - From: Vojtech Szocs vsz...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com Sent: Wednesday, November 5, 2014 6:07:50 PM Subject: Re: [ovirt-devel] Thoughts on modularization - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com Sent: Wednesday, November 5, 2014 4:32:31 PM Subject: Re: [ovirt-devel] Thoughts on modularization - Original Message - From: Vojtech Szocs vsz...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com Sent: Wednesday, November 5, 2014 5:24:14 PM Subject: Re: [ovirt-devel] Thoughts on modularization - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Vojtech Szocs vsz...@redhat.com Cc: devel@ovirt.org, Mark Proctor mdproc...@gmail.com Sent: Wednesday, November 5, 2014 4:12:06 PM Subject: Re: [ovirt-devel] Thoughts on modularization - Original Message - From: Vojtech Szocs vsz...@redhat.com To: devel@ovirt.org Cc: Mark Proctor mdproc...@gmail.com Sent: Wednesday, November 5, 2014 5:04:24 PM Subject: [ovirt-devel] Thoughts on modularization Hi guys, I've discussed this recently with Yair and Mark, I just wanted to share some more thoughts on this topic -- in particular, how modularization problem can be approached (regardless of implementation details). I see two approaches here. The typical one is to define APIs for modules to consume. For example, oVirt Engine extension API has API for auth stuff; oVirt UI plugin API has API for showing tabs and dialogs, etc. The advantage is strict consistency, disadvantage is burden of having to maintain the whole API. With this approach, you tell modules: This is the API to work with system, defining how you can plug into it. Now turn 180 degrees. The other approach, which is really interesting, is to let modules themselves export API. This naturally leads to module hierarchies. Ultimately, this leads to micro-kernel-style development, where all logic resides in modules. Now you might ask: What if we want to employ some consistent work flow across multiple modules? For example, have some pluggable *auth* infra? -- this can be done via some higher
Re: [ovirt-devel] Thoughts on modularization
Hi Mark, sorry for late response. I've looked at GWTP - UberFire migration presentation, looks interesting. It will be best if we discuss everything next week, I'll schedule a meeting on Monday (Nov 10) and also share it on devel-list for anyone interested to participate. @other, if you're interested in GWT, GWT-Platform, GIN, Errai, CDI, UberFire or JavaScript in general, please join this session. Some inline comments below. Regards, Vojtech - Original Message - From: Mark Proctor mdproc...@gmail.com To: Alon Bar-Lev alo...@redhat.com Cc: Vojtech Szocs vsz...@redhat.com, devel@ovirt.org Sent: Wednesday, November 5, 2014 5:06:24 PM Subject: Re: [ovirt-devel] Thoughts on modularization Not sure if my previous email made it to the wider le...@ovirt.org list. I just subscribed :) So I’ll repeat the info. Here is a migration path, with detailed explanation on GWTP mappings: https://docs.google.com/presentation/d/1KImrCvvqaUTgULP-CksUfGwLchJv4uB-dKQSgHPX6rU/edit#slide=id.p14 https://docs.google.com/presentation/d/1KImrCvvqaUTgULP-CksUfGwLchJv4uB-dKQSgHPX6rU/edit#slide=id.p14 Here presentation I gave yesterday, showing all the work we’ve done in BRMS and BPMS and doing. http://blog.athico.com/2014/11/red-hat-jboss-brms-and-bpms-workbench.html http://blog.athico.com/2014/11/red-hat-jboss-brms-and-bpms-workbench.html It also shows a little around our Screens and Perspective plugins, or two units of extensions. Both of which have polyglot bindings (GWTExported, will migrate to @JsType later). Implicitly Maven is our unit of modularity, with maven dependency tree to declare this - however this is not recognised in any internal registry. CDI just scans and picks up any @Screen, @Perspective etc. But could be added, to give physical representation of that unit of modality, with life cycle callbacks - we just haven’t had a need for this yet. For us, I'd like to have modularity implemented in a way to avoid the big GWT app compilation step. Doesn't matter if we ultimately go for pure modular approach or core that invokes modules approach, the big goal for us is to split frontend build into several projects. Maven as unit of modularity is cool but only for compile-time-known projects. I'd like to try a different approach, as you wrote - give them some physical representation and load them at runtime. Our plan over 2015 is to use JsType to create a contract for all the things a module needs. We will then compile modules separately against this, with iframe separation, so each Module is loaded as a separate GWT app. This does mean GWT core repetition, a pita, but that atleast gets us started and may be solvable by a custom GWT linker. Actually, this iframe approach is what we took in oVirt UI plugins! :) So I see that you're approaching modules from GWT perspective, sounds interesting. However, there are already existing JS frameworks and tools that solve modularization (but they come from JS perspective), like RequireJS (AMD) or ES6's module spec. Assuming JS is here to stay as the dominant web UI technology, I'd rather utilize existing ES6 modules than implementing some GWT-specific module system on my own. But let's discuss that in detail next week. Longer term we’d like to work with GWT team. They now use the Closure compiler, this support symbol tables, and I expect how their incremental compiler works for their super dev mode. We want to achieve two things 1) stop recompilation of maven modules, when aggregated into sub projects. 2) declare apis that cannot be pruned 3) export a symbol table to allow later compilation of runtime extensions against those, without requiring a repetition of the GWT core (i.e. problem with our first attempt). Very interesting stuff! :) We will still continue with our polyglot bindings approach, such as with the AngularJS stuff we have done. But I do not see this as the ideal programming model - it hides much of what Errai brings, around event bus, and general java refactoring capabilities. However it is still useful for our customers, who want to write extensions, but do not want to touch or learn GWT. If we take modular approach, nothing prevents us to implement root module in UberFire/Errai and expose high-level API for sub-modules to consume. Sure, GWT/Java brings advantages of Java statically typed language and its development/build tools, I agree. The concept of event bus is also good as it allows decoupling of application components. For me, learning lessons from oVirt UI plugins, I'd rather avoid the have core app as runtime monolith and just expose some JS API for small extensions customers can do scenario. I'd rather treat both core and 3rd party modules/extensions on the same level. Mark On 5 Nov 2014, at 15:32, Alon Bar-Lev alo...@redhat.com wrote: - Original Message - From: Vojtech Szocs vsz...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: devel@ovirt.org,
[ovirt-devel] Meeting with Mark to discuss UberFire project
BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/Belgrade BEGIN:STANDARD DTSTART:16010101T03 TZOFFSETTO:+0100 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU TZNAME:CET END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETTO:+0200 TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU TZNAME:CEST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:f12f5604-1472-46ad-bcc6-a8675daad380 SUMMARY:Meeting with Mark to discuss UberFire project ATTENDEE;CN=Mark Proctor;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU E:mailto:mproc...@redhat.com ATTENDEE;CN=Mark Proctor;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRU E:mailto:mdproc...@gmail.com ATTENDEE;CN=Alexandre Porcelli Bakos;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACT ION;RSVP=TRUE:mailto:aba...@redhat.com ATTENDEE;CN=Alexandre Porcelli;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RS VP=TRUE:mailto:alexandre.porce...@gmail.com ATTENDEE;CN=Eder Ignatowicz;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE:mailto:eigna...@redhat.com ATTENDEE;CN=Eder Ignatowicz;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE:mailto:ignatow...@gmail.com ATTENDEE;CN=Christian Sadilek;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSV P=TRUE:mailto:csadi...@redhat.com ATTENDEE;CN=Christian Sadilek;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSV P=TRUE:mailto:christian.sadi...@gmail.com ATTENDEE;CN=Michael Anstis;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T RUE:mailto:mans...@redhat.com ATTENDEE;CN=Michael Anstis;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T RUE:mailto:michael.ans...@gmail.com ATTENDEE;CN=Jonathan Fuerth;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE:mailto:jfue...@redhat.com ATTENDEE;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:devel@o virt.org ATTENDEE;CN=Einav Cohen;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE :mailto:eco...@redhat.com ATTENDEE;CN=Itamar Heim;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE :mailto:ih...@redhat.com ATTENDEE;CN=Alexander Wels;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T RUE:mailto:aw...@redhat.com ATTENDEE;CN=Greg Sheremeta;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=T RUE:mailto:gsher...@redhat.com ORGANIZER;CN=Vojtech Szocs:mailto:vsz...@redhat.com DTSTART;TZID=Europe/Belgrade:20141110T14 DTEND;TZID=Europe/Belgrade:20141110T16 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE LAST-MODIFIED:20141107T180057Z DTSTAMP:20141107T180057Z SEQUENCE:0 DESCRIPTION:The following is a new meeting request:\n\nSubject: Meeting with Mark to discuss UberFire project \nOrganizer: Vojtech Szocs vszocs@redha t.com \n\nTime: Monday\, November 10\, 2014\, 2:00:00 PM - 4:00:00 PM GMT + 01:00 Belgrade\, Bratislava\, Budapest\, Ljubljana\, Prague\n \nRequired: mp roc...@redhat.com\; mdproc...@gmail.com\; aba...@redhat.com\; alexandre.porc e...@gmail.com\; eigna...@redhat.com\; ignatow...@gmail.com\; csadilek@redha t.com\; christian.sadi...@gmail.com\; mans...@redhat.com\; michael.anstis@gm ail.com\; jfue...@redhat.com \nOptional: devel@ovirt.org\; eco...@redhat.com \; ih...@redhat.com\; aw...@redhat.com\; gsher...@redhat.com \n\n*~*~*~*~*~* ~*~*~*~*\n\nHello\,\n\nin this meeting\, we'll talk about UberFire project a nd related technologies like Errai.\n\nhttp://www.uberfireframework.org/\nht tp://erraiframework.org/\n\nWe'll also provide tech overview of oVirt fronte nd\, where we are today and our future plans.\n\nIf you'd like to propose an other time\, let me know and I'll re-schedule.\n\nTo join the Meeting:\nhttp s://bluejeans.com/8517013908\n\nTo join via Browser:\nhttps://bluejeans.com/ 8517013908/browser\n\nTo join with Lync:\nhttps://bluejeans.com/8517013908/l ync\n\nTo join via Room System:\nVideo Conferencing System: bjn.vc -or- 199. 48.152.152\nMeeting ID: 8517013908\n\nTo join via Phone:\n1) Dial: +44203574 6870 (see all numbers - https://www.intercallonline.com/listNumbersByCode.ac tion?confCode=8517013908)\n2) Enter Conference ID: 8517013908\n\nRegards\,\n Vojtech\n\n BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] GWT-Platform MVP tech session - anyone interested?
Hi guys, few days ago, I gave my ancient (Dec 2011!) GWT-Platform [1] Model-View-Presenter tech session to a couple of colleagues so that they better understand our frontend infra/structure. [1] https://github.com/ArcBees/GWTP This session was meant to explain the core concepts of GWTP framework. Would anyone from community be interested in this session? Regards, Vojtech ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] GWT-Platform MVP tech session - anyone interested?
Yes please. - Original Message - From: Vojtech Szocs vsz...@redhat.com To: devel@ovirt.org Sent: Friday, November 7, 2014 9:13:17 PM Subject: [ovirt-devel] GWT-Platform MVP tech session - anyone interested? Hi guys, few days ago, I gave my ancient (Dec 2011!) GWT-Platform [1] Model-View-Presenter tech session to a couple of colleagues so that they better understand our frontend infra/structure. [1] https://github.com/ArcBees/GWTP This session was meant to explain the core concepts of GWTP framework. Would anyone from community be interested in this session? Regards, Vojtech ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
