Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cap’n Proto

capnproto.org

Post reply on HN
Print view View original

41–50 of 194 posts

Re: Cap’n Proto

#41

Post by kixpanganiban »

kentonv wrote: post #25
kixpanganiban wrote: post #23

Earlier quoted context omitted.

Kenton, thank you for your work on this! I currently use ZeroRPC (which uses protobuf and msgpack) and I was blown away by Cap'n Proto. Really excited to try it out soon! Some questions: - Do you guys have an RPC library written in anything other than C++? If not, could you point me to protocol specs so I can start writing my own? - Since it uses a streaming model to support random access, what encryption method do y…

> - Do you guys have an RPC library written in anything other than C++? If not, could you point me to protocol specs so I can start writing my own? People have written implementations in Rust, Go, and Erlang, and wrappers around the C++ library in Javascript and Python: https://capnproto.org/otherlang.html Scroll down that page for some info on how to start writing an implementation in another language. The RPC proto…

> Hmm, I'm not clear on what you mean by "streaming model" -- I think of "streaming" as the opposite of random access.

Right, sorry, I re-read my comment and confused myself too. Seems like it's bad for me to go on HN without a fresh cup of coffee (it's 10am now here in the Philippines).

Thanks for your swift response, I'll experiment with AES-CTR (since I'm more familiar with it than chacha20). And thanks for pointing out that there are wrappers for Python/Go already, the programming language I use daily and was thinking of building libs for! Again, great work, and I'll stay posted.

Re: Cap’n Proto

#42

Post by zump »

kentonv wrote: post #11

Hi all, Cap'n Proto author here. Thanks for the post. Just wanted to note that although Cap'n Proto hasn't had a blog post or official release in a while, development is active as part of the Sandstorm project ( https://sandstorm.io ). Cap'n Proto -- including the RPC system -- is used extensively in Sandstorm. Sandboxed Sandstorm apps in fact do all their communications with the outside world through a single Cap'n…

Why did you leave Google?

Re: Cap’n Proto

#43

Post by AmrEldib »

throwaway13337 wrote: post #4

To get an overview of the area of binary interchange formats that are language agnostic, the author of Cap'n Proto does a good job in this: https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-... "Protocol Buffers" has been the go-to for a long time but there are more options now. For uses where serialization/deserialization CPU time is a concern, it seems to really a question of Cap'n Proto versus flatbuffer…

Another (brief) overview is on Hanselminutes episode with Kenton Varda http://www.hanselminutes.com/497/your-personal-cloud-platfor...

Re: Cap’n Proto

#44

Post by jtolmar »

Cyph0n wrote: post #5

For some reason, the banner (infinitely faster?), name, and introductory FAQ-style responses made me think the whole thing is a joke - similar to Vanilla JS [1]. Anyways, it seems like a cool project, so I'll be sure to follow its development closely. [1]: http://vanilla-js.com/

If Cap'n Proto is a joke, JSON beat it to the punchline.

What's an efficient binary representation? C Structs. What's an efficient text representation? Javascript objects. But casting arbitrary data to a struct is a horrible idea. And eval'ing anonymous javascript is a horrible idea. Back to the drawing board.

Then N years later someone has the brilliant idea of just... not parsing these formats that idiotic way. And wrote a code generator because the smart way is tedious.

Re: Cap’n Proto

#45

Post by socmag »

kentonv wrote: post #11

Hi all, Cap'n Proto author here. Thanks for the post. Just wanted to note that although Cap'n Proto hasn't had a blog post or official release in a while, development is active as part of the Sandstorm project ( https://sandstorm.io ). Cap'n Proto -- including the RPC system -- is used extensively in Sandstorm. Sandboxed Sandstorm apps in fact do all their communications with the outside world through a single Cap'n…

It sounds really well designed. Great job Cap'n Proto, I've been following your work for some time!

I've also built another message format recently (yes I know, they are never ending). It can't do everything Cap'n Proto can do, although it shares a lot of the same values. One thing I chose to do is to have order preservation on types, which can be very useful. It does mean that the wire format is largely BE though. Anyway, that's an aside.

I'm curious what you think of Amazon ION by the way?

Good stuff!

Re: Cap’n Proto

#46

Post by kentonv »

teddyh wrote: post #40
kentonv wrote: post #37

Earlier quoted context omitted.

Big-endian vs. little-endian is an ancient flamewar that isn't going to go away any time soon, but sure, let's argue. Once you've spent as much time twiddling bits as I have (as the author of proto2 and Cap'n Proto), you start to realize that little endian is much easier to work with than big-endian. For example: - To reinterpret a 64-bit number as 32-bit in BE, you have to add 4 bytes to your pointer. In LE, the poi…

I thought the best summary of the big-endian/little-endian question was written in 1980 in Internet Experiment Note (IEN) 137: https://www.ietf.org/rfc/ien/ien137.txt Also more reader-friendly here: https://www.computer.org/csdl/mags/co/1981/10/01667115.pdf

I think figure 1 illustrates a common misunderstanding. People who object to little-endian are often imagining it in their heads as order (3): they imagine that the bits of each byte are ordered most-significant to least-significant (big-endian), but then for some reason the bytes are ordered the opposite, least-significant to most-significant (little-endian). That indeed would make no sense.

But because most architectures don't provide any way to address individual bits, only bytes, it's entirely up to the observer to decide in which order they want to imagine the bits. When using little-endian, you imagine that the bits are in little-endian order, to be consistent with the bytes, and then everything is nice and consistent.

Re: Cap’n Proto

#47

Post by kentonv »

socmag wrote: post #45
kentonv wrote: post #11

Hi all, Cap'n Proto author here. Thanks for the post. Just wanted to note that although Cap'n Proto hasn't had a blog post or official release in a while, development is active as part of the Sandstorm project ( https://sandstorm.io ). Cap'n Proto -- including the RPC system -- is used extensively in Sandstorm. Sandboxed Sandstorm apps in fact do all their communications with the outside world through a single Cap'n…

It sounds really well designed. Great job Cap'n Proto, I've been following your work for some time! I've also built another message format recently (yes I know, they are never ending). It can't do everything Cap'n Proto can do, although it shares a lot of the same values. One thing I chose to do is to have order preservation on types, which can be very useful. It does mean that the wire format is largely BE though. A…

I haven't looked at Ion before, but it appears to be similar to BSON or Msgpack in that it's a binary format that encodes field names as textual identifiers, to be "self-describing" and avoid the need for an external schema. I generally like schemas, because I like static typing. Of course, static types vs. dynamic types are another ancient flamewar and I'm unlikely to cover any new ground by stating arguments here. :)

Re: Cap’n Proto

#48

Post by paulddraper »

jackmott wrote: post #38
niftich wrote: post #14

I've always liked Cap'n Proto because it was (quite literally) the ideas behind Protobuf taken to an extreme, or, depending on your point-of-view, reduced to its most basic components: data structures already have to sit in memory looking a certain way, why can't we just squirt that on the wire instead of some fancy bespoke type-length-value struct? Of course, the hardest part is convincing everyone that it's not you…

>data structures already have to sit in memory looking a certain way, why can't we just squirt that on the wire instead of some fancy bespoke type-length-value struct? In C/C++ ya can! When making games in college that is exactly what we did. Take the struct, dump it into the socket. I was rather shocked when trying to recreate the same system in C#. "I can't? I CAN'T ?"

Well...that's kind of the point of C#. Enforced memory safety.

Use C if that's not what you want. Don't hammer with a screwdriver.

Re: Cap’n Proto

#49

Post by socmag »

kentonv wrote: post #47
socmag wrote: post #45

Earlier quoted context omitted.

It sounds really well designed. Great job Cap'n Proto, I've been following your work for some time! I've also built another message format recently (yes I know, they are never ending). It can't do everything Cap'n Proto can do, although it shares a lot of the same values. One thing I chose to do is to have order preservation on types, which can be very useful. It does mean that the wire format is largely BE though. A…

I haven't looked at Ion before, but it appears to be similar to BSON or Msgpack in that it's a binary format that encodes field names as textual identifiers, to be "self-describing" and avoid the need for an external schema. I generally like schemas, because I like static typing. Of course, static types vs. dynamic types are another ancient flamewar and I'm unlikely to cover any new ground by stating arguments here.…

Hahaha very true let's not go there. Anyway yes I'm a big fan of richly typed schema-less formats as well, even better when they can be read easily by both JS stuff and C++.

I'll definitely give it a whirl. Cheers!

Re: Cap’n Proto

#50

Post by forrestthewoods »

kentonv wrote: post #11

Hi all, Cap'n Proto author here. Thanks for the post. Just wanted to note that although Cap'n Proto hasn't had a blog post or official release in a while, development is active as part of the Sandstorm project ( https://sandstorm.io ). Cap'n Proto -- including the RPC system -- is used extensively in Sandstorm. Sandboxed Sandstorm apps in fact do all their communications with the outside world through a single Cap'n…

Treating Windows like a red headed step child is why I, with great disappointment, passed on Cap'n'Proto.

Cross platform libraries that really only care about a single platform is an endless source of frustration. :(

Post reply on HN