Advertise and ClientAdvertise messages are not symmetrical.

[KerstinKeller]

Description
Advertise on the server side has the following fields according to the spec, however ClientAdvertise is "missing" the schema field. Is this by intention? If you have the possibility to publish protobuf data, too, this field would certainly be necessary.
Advertise: https://github.com/foxglove/ws-protocol/blob/main/docs/spec.md#advertise
ClientAdvertise: https://github.com/foxglove/ws-protocol/blob/main/docs/spec.md#client-advertise

[foxhubber[bot]]

Internal tracking ticket: FG-3601

[jtbandes]

Converted to a discussion because currently as designed, the server is expected to understand the schemaName and know how to interpret the client-published message data. Client-provided schemas could be a good feature addition if this is a pain point for users. For Studio this could create some complexity because we'd need to teach the app to serialize protobuf data. But if the code is in a custom extension, it could make sense that Studio would not need to worry about it.

[KerstinKeller]

In general, a publisher should always know (and for that matter communicate) the schema of the data that it publishes.
This allows you to have "generic" (we always call them dynamic) subscribers, that can use this schema to interpret the data. (e.g. raw message panel in studio)
It also allows "non generic" subscribers to determine if the publishers data and their expected data actually matches-
If the publisher does not communicate schema data, you cannot have generic subscribers, nor can you validate that a publisher sends the data a publisher expects.

Thinking of ws-procol as a library for Pub / Sub over Websocket, in my opinion Advertise/ ClientAdvertise should contain the same information, no matter if they are advertised by the server or by the client. (For that matter, if not for backwards compatibility it could make sense to rename Advertise to ServerAdvertise.

If Studio can / will fill that information, that's a totally different story.

In eCAL we've designed our pub/sub in such a way that there is a binary level pub/sub which communicates metadata, and binary data (just like ws-protocol does). Then there are convenience functions / objects for users that are e.g. a ProtobufPublisher, ProtobufSubscriber, which "automate" the task to extract type and schema information. So it might make sense to provide something like this, too.

And as you said, extension will be able to provide the schema info.
As of now, Foxglove Studio supports only JSON publishing, which doesn't really have a schema, so no need to populate it.
If it did support publishing protobuf, it would need information about the types that it can publish.
E.g. for the teleop panel, you would need a proto message that describes the output of the panel, and then you will be able to generate schema info for it, too.

[achim-k]

What we can easily do is to add two optional fields schema and schemaEncoding to the client advertise operation. In the end, it's up to the server to decide if it wants to use these values or not. I will draft a quick PR and reference it here.

One use case this would facilitate is a "relay-server" which re-advertises client channels as server channels and simply forwards incoming messages (example: use Foxglove Studio to visualize input of multiple Foxglove iOS apps running in client mode). This is similar to what foxglove-bridge does by advertising ROS topics, which are also then advertised as server channels.

Edit: foxglove/ws-protocol#463

[achim-k]

This has been implemented in foxglove/ws-protocol#463 and published to

• npm (@foxglove/ws-protocol from version 0.6.0)
• pypy (foxglove-websocket from version 0.1.2)

[defunctzombie]

Closing this out as implemented.