search

ISISComputingGroup / lewis-ess

Let's write intricate simulators!
GNU General Public License v3.0
21 stars 19 forks source link

WIP on 297 unsolicited messages, from initial connection and on device events #298

Open auphofBSF opened 3 years ago

auphofBSF commented 3 years ago

This PR attempts to solve #297 , it provides mechanisms to

1) provide an initial message on a TCP client connecting to a StreamInterface - thank you @DominicOram 2) provides a mechanism for a device to generate a message to TCP clients such as from an event and it is sent to all StreamHandlers with connected clients. This could be from regular periodic events or any other non regular computed events

In addition an example is provided in lewis.examples accessible as lewis -k lewis.examples simple_eventing_state_device

Subject to initial review, docs and possibly some tests need to be generated

DominicOram commented 3 years ago

I'm on holiday now until the 28th but will hopefully have a chance to look on my return. Do you have any thoughts @mattclarke?

mattclarke commented 3 years ago

I think this looks promising, obviously as a WIP there are a few rough edges.

I am wondering about whether we need an new abstraction for this type of thing, but I would need to remind myself of how lewis works ;) What I am wondering is if the device should just keep track of whether it has messages to send and something else grabs them and sends them to the adapters rather than giving the device direct access to the adapters.

We'll see what @DominicOram thinks when he gets back, but I think this implementation would be okay.

DominicOram commented 3 years ago

Sorry, I haven't forgotten about this, it's just low priority for me right now. Are you wanting it to be merged soon @auphofBSF?

auphofBSF commented 3 years ago

No problem, I have been on other issues as well, I have been using my forked branch very effectively, but had issues when wanting to push messages from a child device. @mattclarke comment about abstraction is valid and needs some thought. I have added some quick hacks to have messages emitted by the parent device, which got me into looking how hierarchy of devices and partitioning devices works and getting lost in that.

I got to a good working solution, I need to tidy these up and add to this PR

As initially discussed this PR is still WIP, so do not expect it to be Merged as is. I don't know what bandwidth I will have to abstract this messaging further. I will look to push a more refined child/parent message handler and update this PR next week and that may be as far as I can go, Thanks for keeping in touch