Cap'N Proto Elm Implementation

Request Feedback
1

Hey Everyone,
I’m designing and building an Elm implementation for Cap’N Proto. It’s a binary data interchange format similar to Protocol Buffers, but with a few very interesting properties - the major one being a lack of a parsing step that Protobufs require.

I’ve written a design and would love some feedback.

Understand that the API inherently has to be a little more complex than the Protobuf API as we are lazily decoding the bytes.

I don’t expect to be done with an MVP in the next month or two, but hopefully it ends up being useful to more than just me once I’m done.

7 Likes
2

Very interesting ! What’s the reason why you need to wrap the fields when generating decoder/encoder ? Is it to do updates ?

I still haven’t jumped on board with bytes yet. The fact that it’s not possible to make Bytes without a Http request and exclusion from ports makes it very impracticle to debug, but in your case you’ll need a server anyways !

3

Great to see someone working on this, you’ve clearly put a lot of thought into it! I think it would be useful to see a couple high level examples of use, though - perhaps something like:

  • Get a Person Cap’n Proto message as bytes from an HTTP request, decode it and render the person as HTML
  • Construct a Person Cap’n Proto message from an Elm record or similar, and then construct an HTTP request using it
1 Like
4

@Warry, not sure if I understand the question. Are you asking why Capnp.Struct exists? If so, it’s because we lazily read the bytes from the data and I want a way to hide that detail in a way that feels somewhat reasonable in Elm.

@ianmackenzie thanks for the complement. I’m looking to add a few right now. It’ll take me a few days due to my schedule (it basically requires that I implement some parts of the API code so I can provide a good example).

5

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.