Websocket

[Iskander54]

python/nistoar/midas/dbio/websocket.py : Is the python class for the websocket
python/nistoar/midas/dbio/base.py : after initializing the base with the websocket, a message is sent in the create_record function
python/nistoar/midas/dbio/inmem.py : Passing through the initialization of the websocket from the InMemoryFactory to the InMemoryDBClient

python/tests/nistoar/midas/dbio/test_inmem.py : Initializing a websocket and passing it to the initialization of the backend, here inmem

Addition of a new test class to test the asynchronous part of the dbio : the message sent to listening websocket whenever a record is created.

scripts/midas-uwsgi.py : initializing a websocket and passing it in the build of DBIO Backend

[RayPlante]

This is looking pretty good. Here are some initial comments:

• please remove IDE related files (.vscode/launch.json)
• please add a space after commas in function signatures
• I would recommend that you merge in the latest integration branch. This should hopefully remove metadata from the list of files changed. (You'll also get the fix that fixes unit test execution in GitHub.) Expect some possible conflicts as I've been making some changes to some of the core dbio code.
• In your dbio constructors (__init__()), allow the WebSocketServer to be optional--i.e. default to None. This means that throughout the implementation where the instance is used, you will need to put in guards that checks if the self.websocket_server is non-None. Making the websocket server optional will at the very least make most unit tests (the ones that don't use the websocket feature) simpler (see below), but also it will allow the code the be used more easily outside of the web context. (For example, we'll also be building some command-line tools that will use the dbio module.)
• Assuming you've made the WebSocketServer optional, let's move your new unit tests to a separate file (say, test_inmem_websocket.py). The test_inmem.py file can then (more or less) go back to its previous content, in which no WebSocketServer is provided.
• Consider changing some of your names (namely, WebSocketServer and _send_message_async()) to reflect their conceptual role rather than the technology they use to carry out that role. The purpose of your class and the function is to notify clients that changes have occurred, yes? Also, note that it looks like there is only one kind of message that can be sent and that the semantics of that message is implicit--that is, it's meaning is not obvious to someone reading this code. Consider further, then:
  • structure your message to allow for other messages with different semantics to be sent in the future, or
  • otherwise, choose a send function name that explicitly indicates what the message means.

All that said, the implementation looks really good--nice and simple. We still need to make sure this will work under oar-docker, but it might be easier to do that after the integration with the mongo implementation.

[RayPlante]

Seeing this print statement (which should be remove ;-) ) is reminding me of two other considerations:

• would the WebSocketServer benefit from any specific error handling? Will anything blow up if an exception occurs while trying to set up the server or while sending a message? Note that the creation of a record should not fail just because we can't send a message to clients.
• would the implementation benefit from some logging? We don't need to/shouldn't log every message, but it might be helpful to log failed messages.

[Iskander54]

@RayPlante All comments have been taking into account. The only thing I wasn't sure is the message to broadcast. I decided to send this : f"New {self._projcoll} created: {name}".
Let me know if my changes were the ones expected !