Ability to subscribe to specific channels

[carueda]

As briefly discussed with @gtroni, it would be convenient for clients to have the ability to indicate the specific channels to subscribe to. A particular benefit is the potentially significant reduction of network traffic, when, for example, a "remote" user only wants to see positions on the compaswebui app.

[kevinsbarnard]

Hi @carueda, this is already possible. See the example in the README:

lcm-websocket-server --host localhost --port 8765 --channel ".*" your_lcm_types_package

[kevinsbarnard]

Ah, clients. Yes, that would be possible -- I would design it as a regex on the channel name, to be specified in the URL path.

[kevinsbarnard]

@carueda I just implemented this, so you can now subscribe with a regex in the path, e.g.:

http://localhost:8765/.*_SYNC

Built and pushed to Docker hub.

[carueda]

Thanks @kevinsbarnard !

See the example in the README:

 lcm-websocket-server --host localhost --port 8765 --channel ".*" your_lcm_types_package

Ha, I was not thinking about that approach when I entered this ticket, but it could actually be effective! Let me explain:

• in compaswebui, there's now a concept of "deployment," which is determined by a (super)user prior to launching the compaswebui system, that is, via the docker-compose.yml which also involves the lcm-websocker-server.
• the deployment definition includes specification of channels that will be exercised
• such are the channels for the desired filtering
• so, it seems enough to just have the ability to indicate the filtering argument in docker-compose.yml. If not already, the CMD should be uncomplicated to adjust in your dockerfile to allow customization at the docker-compose level.

Make sense?

Now, to respond to the other approach you implemented, let me see if I understand:

From the point of view of compaswebui:

• Opens the websocket connection with the ws:// URL as usual. (Here's where I thought your previous comment regarding a regex was referring to -- see below)
• All traffic gets received by the compaswebui webapp from lcm-websocket-server as usual
• But then the webapp can make a request using the corresponding http url (like http://localhost:8765/.*_SYNC) to request the server to actually apply the indicated filtering for any subsequent notifications.

Is that what you have in mind?

Sorry I was not more specific when I entered this ticket but, regarding a request-based mechanism, I was thinking that the filtering could be specified either as part of the ws:// URL itself when opening the connection, or via a subsequent websocket message from client to server.

For compaswebui purposes, there's no need (at least in short term) for dynamic change of the filtering; only the one indicated at the start or very beginning of the connection.

[kevinsbarnard]

Ah, my bad @carueda! Both approaches are possible; I made an error in explaining what I just implemented.

1. Filtering what the server subscribes to: this can be done from the docker-compose level by setting the CHANNEL environment variable. So, something like:

   lcm-websocket-server:
   container_name: lcm-websocket-server
   # Based on example provided by Kevin Barnard.
   image: mbari/lcm-websocket-server:compas-lcmtypes-0.1.0
   
   # Note: one of the following depending on whether on linux or macOS:
   network_mode: host
   #ports: ['8765:8765']
   
   environment:
   LCM_PACKAGES: compas_lcmtypes
   CHANNEL: FIRST_CHANNEL|SECOND_CHANNEL|THIRD_CHANNEL

2. Filtering on the client subscribes to: I meant to put ws:// instead of http:// -- you can indeed specify the regex as part of the initial URL when opening the connection. So,

   ws://localhost:8765/FIRST_CHANNEL|SECOND_CHANNEL|THIRD_CHANNEL

   URLs are unquoted to handle special characters (e.g. %20 turns into a space)

[carueda]

Great! So, I think I'll start by using the ws:// approach mainly because it will make things simpler for the deployment creator (who can only focus on the associated platforms.yml, while not worrying about tweaking/repeating things in the docker-compose.yml), right @gtroni?