2020-02-28, 12:17 PM
The current standard is somewhat confusing supporting websockets, tcp as well as using http GET and POST requests.
To share a little background: we started with http for data retrieval and WebSockets for streaming. Tcp was added by popular request (I think I remember you saying that tcp is the preferred mechanism, as well as request-response over ws. Ws and http have standard mechanisms for authentication and secure communications and can be used in browsers, as opposed to tcp lacking of all these qualities/features.
Maybe we can improve the specification or add documentation to clear up the confusion? I am way too deep in this to see the it - can you expand on this?
The subscriptions are not forwarded so linking servers is inefficient.
Like with many things open source feature X is added when sufficient interest and somebody willing to do the work meet. The need for forwarded subscriptions surfaced recently - I am willing to help in the implementation but I'll need help in fleshing out the details and use cases. Care to elaborate on this? Preferably in a Github issue.
The data flow is only from server to client (except for PUT which is impractical for streaming data)
This is not true, ws connection has been two way for years and in use by projects like https://github.com/SignalK/SensESP and https://github.com/SignalK/SensESP.
Or am I missing something about 2 way comms? What exactly is not possible?
subscriptions are only supported by websockets so they must be used rather than tcp
No longer true, I implemented this in 1.19, as quickly as I could after OpenCPN integration seemed to provide real interest for it (alas, O will actually be using ws...). See https://github.com/SignalK/signalk-serve...ag/v1.19.0
how to discover the signalk server address is unclear.
Again could you please give a little more detail? The process is documented at https://signalk.org/specification/1.4.0/...ction.html and people have successfully implemented discovery. If there's something missing in the docs (or the discovery mechanism) let's improve them!
To share a little background: we started with http for data retrieval and WebSockets for streaming. Tcp was added by popular request (I think I remember you saying that tcp is the preferred mechanism, as well as request-response over ws. Ws and http have standard mechanisms for authentication and secure communications and can be used in browsers, as opposed to tcp lacking of all these qualities/features.
Maybe we can improve the specification or add documentation to clear up the confusion? I am way too deep in this to see the it - can you expand on this?
The subscriptions are not forwarded so linking servers is inefficient.
Like with many things open source feature X is added when sufficient interest and somebody willing to do the work meet. The need for forwarded subscriptions surfaced recently - I am willing to help in the implementation but I'll need help in fleshing out the details and use cases. Care to elaborate on this? Preferably in a Github issue.
The data flow is only from server to client (except for PUT which is impractical for streaming data)
This is not true, ws connection has been two way for years and in use by projects like https://github.com/SignalK/SensESP and https://github.com/SignalK/SensESP.
Or am I missing something about 2 way comms? What exactly is not possible?
subscriptions are only supported by websockets so they must be used rather than tcp
No longer true, I implemented this in 1.19, as quickly as I could after OpenCPN integration seemed to provide real interest for it (alas, O will actually be using ws...). See https://github.com/SignalK/signalk-serve...ag/v1.19.0
how to discover the signalk server address is unclear.
Again could you please give a little more detail? The process is documented at https://signalk.org/specification/1.4.0/...ction.html and people have successfully implemented discovery. If there's something missing in the docs (or the discovery mechanism) let's improve them!