Consider getting ROS1 message definition from topic connection header

[achim-k]

I wonder if it may be better to unconditionally use the socket-based approach. It has the overhead of opening a socket, initiating a two-way handshake, then closing the socket, only to reopen it again if the client requests a subscription. But even for 1000-topic graphs this is a one-time cost of opening and then closing 1000 sockets. I don't think that's a bad price to pay for always having the correct message definitions and not worrying whether what is locally on disk matches what is actually being advertised.

Originally posted by @jhurliman in #29 (comment)

[amacneil]

Do we need to have the schema available when advertising? Can we advertise with just the topic name, then provide the schema content immediately after the client subscribes?

[achim-k]

The current ws-protocol spec requires the schema to be known when the channel is advertised. Not sure if we can / want to change this, I guess this would require also quite some changes to Studio.

[amacneil]

Yeah, we can evolve the protocol in a backwards compatible way if we need to though (require newer version of studio when using ros-foxglove-bridge).

Just an idea if we want to avoid "open up 1000 tcp sockets" on startup.

[jhurliman]

Studio needs the full set of schemas along with topic+datatype list when it connects to a data source. Rearchitecting Studio to fetch schemas on demand would be a large UX and technical undertaking.

I don't think we need to avoid opening up 1000 TCP sockets on startup. I would expect it to take less than one second, happen before any WebSocket clients connect, and have a negligible impact on even resource-constrained systems while it is happening.