Hi Greg, On Thu, Nov 7, 2024 at 4:51 AM Greg Troxel <g...@lexort.com> wrote:
> > Is there an open bug at sioclient that "release is overdue and project > is unhealthy", more or less? If not, I think that's in order, just so > everybody can be straightforward. > I looked at their repo and probably the closest to such a bug would be https://github.com/socketio/socket.io-client-cpp/issues/419 ("When can we expect a v4? Any way to support timeout on emit?"). There's also https://github.com/socketio/socket.io-client-cpp/pull/346 for Debian packaging that hasn't been touched since 2022. > Is it really necessary to use sioclient? You mention "FreeDV > Reporter", but why couldn't both that and freedv switch to something > else? There is grpc, mqtt, websockets, and surely other things. > socket.io actually uses websockets on the backend, falling back to IIRC HTTP long polling. In effect, it's supposed to be a "more reliable" version of them. That said, I did end up having to home-roll my own minimal C++ version for ezDV ( https://github.com/tmiw/ezDV/blob/main/firmware/main/network/FreeDVReporterTask.cpp) as porting socket.io-client-cpp to ESP32 would have been a more massive effort. This could theoretically be extended for the main FreeDV application (i.e. to support two-way communication) if project priorities were to become such that this was needed (see https://freedv.org/radio-autoencoder/ for more information on our current priorities). > Is the release version of sioclient actually problematic, if the > FreeDV Reporter site ran it too? Why is that site using a non-release > version? > As part of the handshaking process with the server, we send an JSON dictionary containing the user's callsign and some other content (the "additional data" mentioned in the protocol document over at https://socket.io/docs/v4/socket-io-protocol/#connection-to-a-namespace). This support was added in https://github.com/socketio/socket.io-client-cpp/commit/23f243ff555aa86193aa673d616ba6cca7899256, after 3.1.0 was released. Offhand, I don't *think* we use anything else that was added since their last release, but we'd need to do some more testing to confirm. Thanks, -Mooneer K6AQ
_______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
