Split rosbridge client code into a separate package

This issue has been tracked since 2021-09-10.

In a recently ROS WebTools working group we discussed making the rosbridge client (websocket) code available as a separate package. The motivation is to decouple being able to write tools that talk to the rosbridge server which might have different ideas or requirements than what roslibjs has around URDF, TF, etc. Such tools would benefit from shared packages for the rosbridge client tho.

I'm willing to setup the new package under the RobotWebTools umbrella and seed it with the code from roslibjs (maintaining license, authors credits, and linkback).

Hoping to gage interest from any active (or inactive) maintainers on this library and get feedback on this proposal. Maybe it was considered and there are some posts I can read about thinking at the time?

/cc some folks that I think might have thoughts but please feel free to mention others.
@MatthijsBurgh @jihoonl

MatthijsBurgh wrote this answer on 2021-09-10

I don't mind you extracting a part of the library as long as you provide the same functionality as roslibjs requires.

But I think you should first come up with a tool or something that would use the websocket, but conflict with the rest of roslibjs, otherwise you are just creating work for yourself.

Also it is not really clear what classes you want to extract.

defunctzombie wrote this answer on 2021-09-10

But I think you should first come up with a tool or something that would use the websocket, but conflict with the rest of roslibjs, otherwise you are just creating work for yourself.

In Foxglove Studio we would use the websocket connection but don't need the other functionality as we use different libraries for those features.

trusktr wrote this answer on 2021-09-18

@defunctzombie Hello, can you import the classes you need from roslib, then your app build will only include those classes?

I have converted the code to ES Modules in #475, which shoujld make it easier to import classes directly instead of importing from a bundle or index file.

At the very least what we can do in this repo (if it isn't the case already) is ensure that the rosbridge code is not coupled to other code, so that importing it will not lead to other things being also included. It would be similar to with three.js where importing a math class from it's math/ folder will not also import the entire library; the parts of threejs are decoupled in this sense, and one can, for example, use the Vector3 class without any rendering classes like Geometry or Mesh being included in the final application.

defunctzombie wrote this answer on 2021-09-18

I think it's useful to have this as a separate library and package as it is completely unrelated to the other components. The rosbridge is itself a ros ecosystem module and not a core component.

amacneil wrote this answer on 2021-09-18

I think there is a strong argument for rosbridge (both client and server) being independent from roslibjs (as mentioned above, in Foxglove Studio we only need rosbridge). This will make it clearer for people trying to use rosbridge in their project how they should consume it.

@trusktr @MatthijsBurgh any chance you're able to join the next ros-web working group meeting (Thursday) to discuss?

https://github.com/RobotWebTools/community#meetings
https://groups.google.com/g/ros-webtools-working-group

MatthijsBurgh wrote this answer on 2021-09-18

I am not able to join on Thursday. I think @trusktr has more JS knowledge and a better vision so I think it would be good if he could join.

trusktr wrote this answer on 2021-09-19

@amacneil Hello! Can you send me an invite to that (email on my profile). I think it will be easier to split things into a new package once the tooling across projects is consolidated (my PRs here and in ros3d start to make both projects use the same tooling instead of differing setups).

amacneil wrote this answer on 2021-09-19

Yes! Two options, either join the ROS webtools google group (that group is on the meeting invite), or add the public ROS events calendar (but it shows all ROS working groups, not just this one).

Rayman wrote this answer on 2021-09-20

How do you want to make the split? Can you elaborate more? I don't understand this PR because roslibjs == rosbridge client code.

You could make an argument tf and urdf could belong in a separate package, but I've never seen a robot that doesn't use them.

If you want to use parts of the code, then you are free to do so, we don't have to split this package in two. We just need to make sure #475 get's merged.

amacneil wrote this answer on 2021-09-20

I don't understand this PR because roslibjs == rosbridge client code

This actually surprises me, the repo description says "The Standard ROS JavaScript Library" and the readme doesn't mention rosbridge anywhere. Should we rename this repo to rosbridge-javascript and publish it on npm as rosbridge then?

That's what I would expect from this issue (and where the motivation is coming from) - a package on npm that is clearly identified as a rosbridge client. We want to make it clear for folks getting started with rosbridge where the client/js library lives.

You could make an argument tf and urdf could belong in a separate package, but I've never seen a robot that doesn't use them.

That seems reasonable. Robots might nearly always use them, but it's fairly common to build web interfaces which don't need this level of detail. They could also continue to live in this package, but if this package was renamed to rosbridge it might suddenly feel a bit weird.

jihoonl wrote this answer on 2021-09-27

I don't have any strong preference as I am not an active developer. But, please consider maintenance costs and side-effects that could be occurred by code split. Separating code often introduced code defragmentation and harder maintenance in a long run from my experiences.

More Details About Repo
Owner Name RobotWebTools
Repo Name roslibjs
Full Name RobotWebTools/roslibjs
Language JavaScript
Created Date 2013-03-15
Updated Date 2022-11-22
Star Count 549
Watcher Count 54
Fork Count 340
Issue Count 66

YOU MAY BE INTERESTED

Issue Title Created Date Updated Date