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

71–80 of 194 posts

Re: Cap’n Proto

#71

Post by sandGorgon »

kentonv wrote: post #58
sandGorgon wrote: post #54

How do you pronounce the name? If libreoffice is bad.. This name is absolutely impossible. Is it captain? Is it cap+n+proto? A lot of collaboration is verbal - people sit around and talk about stuff. I don't know if it is a fun take on an American word... But it is impossible to use in the rest of the world. I really wish you would call it something else... Unless it is personal for you :(

CAP-ən PRO-to But "Captain Proto" is acceptable if you have trouble with the contraction. Or you can also think of it as "Cap-and-Proto". Which is an intentional pun ("capabilities and protocols", or something). Googling either of these will get you to the right place, so I think it gets the job done.

Protocap maybe?

Btw, you rank in the 5th result for "protocap" on Google.

Now that's a name all of us can pronounce!

Re: Cap’n Proto

#72

Post by QuercusMax »

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 ?"

That's an absolutely terrible idea if you want any kind of forward / backward compatibility. Just about any system is better than dumping structs over the network, once you're dealing with a system that can evolve.

Re: Cap’n Proto

#73

Post by throwaway_exer »

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/

Except that Vanilla JS is not a joke at all.

Re: Cap’n Proto

#75

Post by aidenn0 »

kixpanganiban wrote: post #41
kentonv wrote: post #25

Earlier quoted context omitted.

> - 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 pointi…

Also as a note, both ciphers suggested are stream ciphers, so you will need some way of authenticating. Depending on your needs, you may consider using something like libsodium that takes care of all of that for you:

https://download.libsodium.org/libsodium/content/secret-key_...

Re: Cap’n Proto

#76

Post by pcr0 »

kentonv wrote: post #37
wtbob wrote: post #31

> The Cap’n Proto encoding is appropriate both as a data interchange format and an in-memory representation, so once your structure is built, you can simply write the bytes straight out to disk! Eh, I'd rather pay the cost of serialisation once and deserialisation once, and then access my data for as close to free as possible, rather than relying on a compiler to actually inline calls properly. > Integers use little-…

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've just began learning about endianness and I'm sorry if this comes off as pedantic, but doesn't the last example refer to bit numbering rather than (byte) endianness?

https://en.wikipedia.org/wiki/Bit_numbering

Re: Cap’n Proto

#77

Post by aidenn0 »

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.…

Schemas are IMO the only way to go when you are transferring between heterogenous languages, even when all languages involved are untyped.

Consider javascript talking to common lisp. Of course JSON has a canonical mapping to javascript, but it does not for common lisp. Should a JS array be a lisp list or vector? Should lisp's NIL be false or null? Should a JS object decode to an alist, plist, or hash-table? &ct.

Re: Cap’n Proto

#78

Post by Perceptes »

kentonv wrote: post #70
Perceptes wrote: post #67

Big fan of what Sandstorm is doing, both with Sandstorm itself and this component. I really want to use this instead of gRPC, as it seems technically superior, but language bindings and adoption across language ecosystems are likely to be a big downside given that (as Kenton mentions in a comment elsewhere here) Sandstorm isn't really interested in Cap'n Proto being widely adopted. All my new stuff is built in Rust,…

FWIW, language interoperability is of interest to Sandstorm since apps can be written in many languages. But we're only 7 people with a lot on our plate, so unfortunately we can't currently be the ones to go around implementing Cap'n Proto in every language. That will change as Sandstorm grows.

Great news, and thanks for the response! I don't have an immediate need for a system like this, so perhaps by the time I do there will be broader adoption.

Re: Cap’n Proto

#79

Post by jcoffland »

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…

Recently I've started compiling more of my code for Windows using Mingw (or clang). Performance is very good and you can build in Linux for Windows inside a Docker container. You can even build Windows installers using NSIS. I've also tried to do this for OSX but with less success.

Re: Cap’n Proto

#80

Post by wtbob »

kentonv wrote: post #60
wtbob wrote: post #57

Earlier quoted context omitted.

> To reinterpret a 64-bit number as 32-bit in BE, you have to add 4 bytes to your pointer. In LE, the pointer doesn't change. But one shouldn't do that very often: those are two different types. The slight cost of adding a pointer is negligible. > Just about any arithmetic operation on integers (e.g. adding) starts from the least-significant bits and moves up. It's nice if that can mean iterating forward from the sta…

That line of argument suggests you'd be happier with a human-readable format like JSON. Which is another eternal flamewar that we aren't likely to resolve here. Needless to say I like binary formats. :)

> That line of argument suggests you'd be happier with a human-readable format like JSON.

Oh, that's rude. There's a huge difference between flipping a few bytes and committing a public indecency against God and man like JSON.

Post reply on HN