Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

auphofBSF
Copy link

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 and others added 4 commits June 16, 2021 10:04
A CRUDE but working first attempt
(But throws Errors and Eventually Disconnects)
to all stream handlers

check method names
check attachement of adapters to devices in simulation
@DominicOram
Copy link
Contributor

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?

@@ -178,7 +195,12 @@ def close(self):

def process(self, msec):
for handler in self._accepted_connections:
if self._device_event_message:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps I am missing something but where does self._device_event_message get set?

@mattclarke
Copy link
Member

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
Copy link
Contributor

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
Copy link
Author

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

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants