Hi All, I would like to take this opportunity to start a discussion about the possibility of implementing a user facing change notifications.
The benefit of this would be to remove the need for periodic polling from frontends and other services that consume our REST API. Also implmenting a common infrastructure on the backend for event notifications (e.g. CDI events) would further reduce the internal need for polling the DB by the backend itself, maybe even reducing the need to use DB for some things and just keep them in memory and updated by CDI event observers. There are many solutions how to provide the user-facing part of the notifications: Doctor Rest, MQTT, websocket, server-sent events, ... . Ideally these notifications should be consumable both by web browser (webadmin/userportal) but also by other services (such as ManageIQ), or other REST clients such as moVirt android client. But regardless of the chosen user-facing transport, I believe a common infrastructure can be implemented on the BLL layer with the usage of CDI events fired from commands. I see 2 major sources of changes in the engine (please correct me if this is wrong): 1) CRUD & management commands 2) Vms/Hosts monitoring the changes originating from 2) are AFAIK very localized and not so numerous so a manual firing of appropriate events for VMs and Hosts could be added here. The 1) case is more extensive in terms of required code changes. While a manual solution would still be feasible, I believe there is place for a more automated/declarative way. One solution for 1) that comes to my mind are simple command-level annotations covering the Created, Updated, Removed (C, U, and D from CRUD) cases. The goal here is to fire the appropriate CDI events when an entity is created/updated/deleted. Since commands usually contain getters for entities they work with (such as getVm(), getVds(), getStorageDomain() ...) It should be sufficient for the most common simple cases (of course this will not cover everything) to use annotation @Creates, @Updates, @Removes on the commands classes, where parameters of the annotation should specify the getter method that returns the affected entity (VM/VDS/StorageDomain...). This could be specified by the entity class token or method name (depending on the level of "magic" one prefers :-) and the CommandBase infrastructure would then collect those annotations and upon successful completion of the command fire the appropriate events. Example #1: @Updates('getVm') // or @Updates(VM.class)? public class UpdateVmCommand<...> extends VmManagementComandBase ... Note that since Java 8 we have repeatable annotations so we can have more complex commands that affect more entities. Example #2: @Updates(Vm.class) @Updates(VmTemplate.class) // possibly also some @Creates and @Removes annotations or their combination public class ContrivedExampleCommand extends SomeCommandBase the infrastructure would then look upon successful completion of the command on the getVm() and getVmTemplate() methods, invoke them, determine the resulting types of entities VM and VmTemplate and since the annotations used were @Updates fire CDI event equivalent to @Inject @Updated // our custom CDI qualifier Event<VM> vmChangedEvent; and anologously for VmTemplate. But regardless of the exact implementation of the CDI event firing: whether manual, the above proposal, or some crazy usage of AspectJ - the interface for the rest of the code should always be the like this: public void onVmChanged(@Observes @Updated VM vm) { // .... } On top of this, I believe, we can build the user-facing part of push notifications and also improve our existing backend code. Thank you for reading this long email and I welcome any comments or counter-proposals you might have on this topic :-) Best regards, Martin _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel