Propose/dds over http

[MikeNeilson]

Problem Description

The current DDS protocol assume a raw tcp port and requires that our applications directly implement all possible operations and contigiencies. It also makes assumptions about operations that are no longer as practical.

Solution

I have been describing a pure HTTPS based method of handling LRGS-LRGS/DECODES connection that should make development easier.

• Only Data Transfer is covered directly
• Authentication and Authorization are handled by the implementation (though we will specify some expected standards like using the Authorization header)
• Directly documented is a long-polling method that can work all the way back to HTTP/1.1

TODO/Desired.:

• WebSockets?
• ServerSentEvents

how you tested the change

Describe what was done to test the change. This section can be left blank
if automated tests demonstrating usage are provided in the PR.

Where the following done:

• Tests. Check all that apply:
  • Unit tests created or modified that run during ant test.
  • Integration tests created or modified that run during integration testing
    (Formerly called regression tests.)
  • Test procedure descriptions for manual testing
• Was relevant documentation updated?
• Were relevant config element (e.g. XML data) updated as appropriate

If you aren't sure leave unchecked and we will help guide you to want needs changing where.

[MikeNeilson]

@opendcs/opendcs-core-devs @opendcs/opendcs-dcpmon-devs @opendcs/opendcs-triage
This is a very early start; however, as I have gotten any detail down I though it would be a good time to solicit any feedback.

[krowvin]

WebSockets?

In my opinion https/websockets make sense for the bidirectonal communication but they're stateful and may not be as useful for something like dcpmon where a simple REST API could return what you need. (I.e. the client doesn't need anything more than short/long polling)

But from a standpoint of client and server consumer applications a websocket server would be great. It would really let us take advantage of a pub/sub architecture.

I would be curious what work has been done by the current OpenDCS web interface group, and if there is any potential overlap here.

Server Sent Events

I've never worked with SSE but from what I read it is server to client only. If it's simpler to implement then i'm sure it would work for things like configuration changes when saved on one client being pushed out to all the other clients, for example.

@DanielTOsborne
Any thoughts on this? If we can handle the data fetch purely in client/JS we might not need a java backend - unless of course we help implement the socket server/some form of HTTPS/API

[MikeNeilson]

Agree, I certainly wouldn't set WebSockets as the only option, but we had some thoughts on "federation" of data. e.g. a trusted system could also push data.

Based on work with SSE in the CWMS-Data-Api, it's not... terrible, but like you said doesn't seem commonly used. USACE/cwms-data-api#518

There is likely overlap with that group, but this is just defining what the standard should be, and pretty much for the reason above you just stated, why should your webdisplay require an additional Java API.

But remember this is a standard for LRGSes to to communicate with each other and interested other system to know how to retrieve/push data.