Move cached-data-server and websocket-server to a functionality of an OpenRVDAS API implementation.

[webbpinner]

This may be too big a change but hear me out...

What uses the cache-data-server??? As far as I can tell only the Django-based web-client and the display widgets

What uses the websocket-server??? As far as I can tell only the Django-based web-client and the display widgets

I think I could make a good argument that the cached-data-server and websocket server are BOTH not used unless OpenRVDAS is controlled via web-interface and/or the operator is using web-based widgets.

If OpenRVDAS were to be deployed on a stand-alone deploy-able sensor package, like an AUV, subsea moring-based package, etc where only the DAS functionality was needed then the websocket server and cached-data-server would NOT be used.

Recommend moving the cache-data-server and websocket-server to be handled by API implementation.

Examples of data flow under this proposed change (assume there are 2 web-clients actively monitoring the server):

• Web-client 1 requests to change the mode of the server:

1. Web-client clicks link to change mode of server.
2. Web-server receives request from web-client, makes API call to logger-manager to change modes.
3. Web-server responds to all clients via websocket that there is a mode change pending.
4. Logger-manager completes mode change, makes API call to update the active mode in the data store (django)
5. Web-server notifies all connected clients via websocket that change has been completed, optionally if the mode change was unsuccessful the logger-manager submits an API call with the appropriate log message, which is committed to datastore, the web-server updates all clients via websocket that there was an error changing modes.

[davidpablocohn]

CDS and web functionality are not needed to run the logger manager. It can run alone, either taking commands from the console or in headless mode:

server/logger_manager.py --config test/NBP1406/NBP1406_cruise.yaml --mode log [ --no-console ]

If the logger_manager is started with a --data_server_websocket flag, it will try to connect to a CDS there and keep it apprised of its status. And if the cruise definition specifies loggers writing to websockets, they will try to open and write to them, but there's nothing in the code that requires any websocketing.

(The 'websocket_server.py' code is actually vestigial, and not used anywhere in the OpenRVDAS code.)

If the logger_manager is started with the --database django (or hapi) flag, it will look to that DB for changes.

I think i understand the architecture you're proposing, and it's a plausible way forward. But I think there are arguments against it, as well. For now, I'm going to let things sit as they are.

On Wed, Oct 2, 2019 at 8:06 AM Webb Pinner [email protected] wrote:

This may be too big a change but hear me out...

What uses the cache-data-server??? As far as I can tell only the Django-based web-client and the display widgets

What uses the websocket-server??? As far as I can tell only the Django-based web-client and the display widgets

I think I could make a good argument that the cached-data-server and websocket server are BOTH not used unless OpenRVDAS is controlled via web-interface and/or the operator is using web-based widgets.

If OpenRVDAS were to be deployed on a stand-alone deploy-able sensor package, like an AUV, subsea moring-based package, etc where only the DAS functionality was needed then the websocket server and cached-data-server would NOT be used.

Recommend moving the cache-data-server and websocket-server to be handled by API implementation.

Examples of data flow under this proposed change (assume there are 2 web-clients actively monitoring the server):

• Web-client 1 requests to change the mode of the server:

1. Web-client clicks link to change mode of server.
2. Web-server receives request from web-client, makes API call to logger-manager to change modes.
3. Web-server responds to all clients via websocket that there is a mode change pending.
4. Logger-manager completes mode change, makes API call to update the active mode in the data store (django)
5. Web-server notifies all connected clients via websocket that change has been completed, optionally if the mode change was unsuccessful the logger-manager submits an API call with the appropriate log message, which is committed to datastore, the web-server updates all clients via websocket that there was an error changing modes.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/davidpablocohn/openrvdas/issues/165?email_source=notifications&email_token=AFO7V3XOSWOZKR7HPXZMTULQMS2HHA5CNFSM4I4XTYP2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HPFBO2A, or mute the thread https://github.com/notifications/unsubscribe-auth/AFO7V3XN5KN6LLPPSRMUYILQMS2HHANCNFSM4I4XTYPQ .