asterics
Deliver model events through SSE channel
Give the ability to ReST api clients to consume and trigger model events. Check if such a functionality is currently possible (using the listener pattern), or if we need to do some refactoring.
We currently support "ARE events" (deploy, start, pause, resume, stop). By "model events" i am reffering to the events produced (in a specific model) during runtime. Quoting an old email conversation:
"Maybe the DeploymentManager should keep track of listeners for model events (and the SSE-service could be such a listener). The listener would be able to subscribe for single eventtypes. Vice versa it should allow to trigger an event to a component."
So the ARE events are implemented but the model events not, right? Thx
Am 13.05.2016 um 19:05 schrieb mariokom:
We currently support "ARE events" (deploy, start, pause, resume, stop). By "model events" i am reffering to the events produced (in a specific model) during runtime. Quoting an old email converstion:
"Maybe the DeploymentManager should keep track of listeners for model events (and the SSE-service could be such a listener). The listener would be able to subscribe for single eventtypes. Vice versa it should allow to trigger an event to a component."
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/asterics/AsTeRICS/issues/114#issuecomment-219101870
Martin Deinhofer, MSc Research and Development, International Projects
University of Applied Sciences Technikum Wien Hoechstaedtplatz 6, 1200 Vienna, Austria, Europe T: +43 1 333 40 77-297, F: +43 1 333 40 77-99 297 E: [email protected] I: embsys.technikum-wien.at
Model events are now delivered via the SSE mechanism, along with channel data and runtime component property changes
Greeeeaaaaaaaaaaaaaaaaaaaaaaaat Marios!! :+1:
Works very great! Just one thing: Now when I see it running, I am wondering if it would not be more useful if someone could directly register for output ports and event triggerers instead of registering for a channel connection. Or maybe both makes sense??!?
Do you know what I mean?
Glad it worked for you Martin :)
Yes i understand your point and it is - semantically speaking - better to register on ports. A componentXX_portXX name is also more descriptive in comparison to the 'binding.XX' name of a data channel. We have to clearly state though, that data will be transmitted only from ports connected with a channel (i think this is how ARE works, please correct me if i am wrong), and this is the reason i went with channels. It is not a major issue, so if you also i agree, i can change the subscription to be per-port-name and just document that the not connected ports will not transmit anything.
IMHO keeping both will not add anything and it will bring confussion to external clients that will not be familiar with the ARE terminology and core components.
Sounds like a great improvement, Marios, thanks for that - looking forward to trying it out!
@Martin: I don't see the benefit of changing it to ports though - in the ACS it would make sense to show the data on the channels - having to subscribe to ports would only make the implementation more complex.
I think registering to the output port is much more intuitive. Imagine somebody would only like to use a plugin to interface some HW and directly access the output in a Web UI (e.g. sensor data of a microcontroller, SignalGenerator,...). Why would I have to add a channel and a receiving plugin in this case?
@Stefan: more complex means one method call more ;-) @Marios: Actually the ports do send data, but you would have to register your code as IRuntimeOutputPort at the respective port, as I did it for the WebSocket plugin to deliver the data actually to the websocket. https://github.com/asterics/AsTeRICS/blob/master/ARE/services/WebService/src/main/java/eu/asterics/mw/webservice/AstericsDataApplication.java#L105
Sorry for the inconvinience, I know in summer we talked about an abstract class. That one would still make sense if you want to allow the registration to listen to data coming to an input port.
The same would be the case for events: I would like to be able to directly react to an event in my WebUI, why should I have to create an event channel first??
I guess we differ here on the topic of intuition g, but nevermind, if you have a usecase where you need the data on port-level, it is fine with me (it will be more than one method call, but I will cope :-P)
@deinhofer : Yes this is what i ment by saying that they have to be connected with a channel. I am already making modifications to make it work with ports instead of channels.
@kingcole : Yes i can understand that from the ACS' perspective the channel makes more sense. There is a connection between channel and channel source anyway, that may lead to the output-port/event triggerer. I hope that it will not be to hard to adjust to these changes.
@mariokom: Thanks, you are my personal hero!! :-) https://github.com/asterics/AsTeRICS/commit/960a6b9382f5cf6f4b4c315c09aab538eed41057
@kingcole: Also thanks for your understanding!!
@mariokom: Will you be able to do the change: directly listening to output ports without a channel?