Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cap n proto support for XVIz #718

Open
ShekharSumanP opened this issue Oct 2, 2022 · 1 comment
Open

Cap n proto support for XVIz #718

ShekharSumanP opened this issue Oct 2, 2022 · 1 comment
Assignees

Comments

@ShekharSumanP
Copy link

Hi! Thanks for the amazing work.

I wanted to know your opinions about using capnp for XVIZ protocol and what are the things that one should know before going onto working on this.

All the suggestions are welcomed and thanks for your answers. : )

@twojtasz
Copy link
Contributor

twojtasz commented Oct 5, 2022

This would currently require a large effort, but doable.

Specifically, XVIZ started as JSON, and Protobuf followed. The companion Streetscape.gl code does not "read" messages directly, it uses @xviz/parser which handles the different format schema's and "normalizes" the data.

This is the first problem. That "normalized" schema is not well documented and at this point is a private contract between @xviz/parser & streetscape.gl

This is good and bad. Bad because it is difficult to define exactly what steps need to be taken. Good in that since we don't read directly from a specific format but do have a parsing phase, it means you can use cap'n'proto and just create your own parsing to match the normalized structure. There is a hit taken here as it does require a linear pass over the message, but this is not been a significant problem so far.

Given the above, you could derive/create cap'n proto messages (not sure if this can be derived from the protobuf defs?).
The flow would be

  1. create necessary Builder API to output cap't proto
  2. create parsing library to decode cap't proto and "normalize" per streetscape.gl
  3. get this data into a LogInterface such that streetscape.gl could use it

There are lots of details missing here. However, this is similar to work I have done privately, specifically the custom parsing part and normalization. It is paired with some Typescript definitions which go a long way toward at least providing some support to "document" these private interfaces between @xviz/parse and streetscape.gl.

So, I would love to get these rolled back into these projects as it would be practically required if you wanted to try a cap't proto route. I really want to get these projects updated. It is just really hard to find time, but I know it's desperately needed. I hope the above helps, and we can continue if you choose to pursue this.

The top priorities are

  1. Typescript support
  2. dependency/modernization update
  3. new feature work

Custom parsing like the above would fit somewhere in 2 & 3. But 🤞 I can start on 1 sometime in december

@twojtasz twojtasz self-assigned this Oct 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants