Grey

CI is currently failing because of an upstream issue which is fixed by https://github.com/ros2-rust/rosidl_runtime_rs/pull/13

When I did a squash merge to resolve merge conflicts from https://github.com/ros2-rust/ros2_rust/pull/446, I lost the commit history from https://github.com/ros2-rust/ros2_rust/pull/440 which this PR was based off of. I've added [775b170](https://github.com/ros2-rust/ros2_rust/pull/480/commits/775b170811518aa0c4e02f52c45b24963d9d64f7) which...

@esteve no worries, merge conflicts are fixed!

Interesting... I do like the idea of not duplicating the doc comments and the error attribute. The [example](https://github.com/yaahc/displaydoc?tab=readme-ov-file#example) that combines `displaydoc` and `thiserror` looks very sensible. I'll give that a...

The point would be that the rclrs API would be able to work exactly as-is for a web application by just setting a feature flag and not needing to change...

If it helps anything, I could implement the rosbridge websocket protocol in a separate crate, and then `rclrs` can have an optional dependency on that crate for when the `"rosbridge"`...

> Yes, that's what ros2wasm did, I'm afraid I don't see where the issue is, could you elaborate? Thanks. Web dev is definitely not my expertise so I'd love to...

> It having better perfomance is debatable, given that the rcl and rmw layers are extremely thin I agree on this part, and I didn't mean to insinuate that rcl...

> How come we'll never have web browser compatiblity when you could already just use rmw_wasm now and run rclrs on top? 😉 I'm talking about web browser compatibility that...

> we could move common structs and functions into a separate crate called rclrs_api that you can reuse for your rclrs-like layer and then you'd be free to implement support...