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

Cap'n Proto 0.9

capnproto.org

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Cap'n Proto 0.9

#31

Post by c-cube »

hamandcheese wrote: post #25
caturopath wrote: post #9

Earlier quoted context omitted.

The 'cap' in Cap'n Proto is for https://en.wikipedia.org/wiki/Capability-based_security -- Cap'n Proto isn't actually an RPC system, it's a capabilities framework. You can work with results without actually having the results, e.g. before the results exist.

> The 'cap' in Cap'n Proto is for https://en.wikipedia.org/wiki/Capability-based_security This seems to go completely unmentioned on the home page, other than the word “capability system” in the very first sentence. What does capability based security mean for a data interchange format? The notion hardly makes any sense to me. From the homepage: “Think JSON, except binary.” What would JSON look like with capability-b…

It's a promise you can send to other processes, even to the machine that is supposed to fulfill that promise. That allows batching of calls that depend on one another.

Re: Cap'n Proto 0.9

#32

Post by Communitivity »

moonchrome wrote: post #28
hamandcheese wrote: post #3

Aside from the speed benefits, are there any other major advantages of Cap’n Proto? I’ve been using grpc/protobuf with Java and Scala. Overall I like it, but the grpc Java library does feel like it comes with a lot of opinions baked in. As an example, I was looking in to implementing automatic retries on the client side for certain classes of error. Grpc Java has some experimental retry support, but it seemed tightly…

If you're looking for a binary serialisation library that generates simpler/more readable code and doesn't do parsing look into flatbuffers. Going through generated protobuff code in . NET last time I used it was vomit inducing. Flatbuffers don't provide RPC AFAIK so not comparable with gRPC Capnproto tried to do too much with distributed objects and RPC, I was looking into it years ago but it still seems like the C+…

For your own sanity, please stay away from Flatbuffers. The key here is 'doesn't do parsing'. I used it, and wound up writing a ton of extract code to unpack things in the way I wanted. Behind the scenes everything in FlatBuffers is stored in a byte array or byte buffer. It can be made to work, but protobuffs worked better for me.

Caveats:

1) I needed to work in C++ and Java

2) I was transporting serialized messages over ZeroMQ

Re: Cap'n Proto 0.9

#34

Post by kentonv »

lilyball wrote: post #10

What will it take before it’s declared as 1.0?

There's a change I want to make to the kj::AsyncOutputStream interface, to make it have an explicit `end()` method rather than assuming EOF on destruction. That's backwards-incompatible, so I don't want to declare 1.0 until I get around to doing it...

Also, I need to make a web site for KJ.

Re: Cap'n Proto 0.9

#35

Post by kentonv »

hamandcheese wrote: post #25
caturopath wrote: post #9

Earlier quoted context omitted.

The 'cap' in Cap'n Proto is for https://en.wikipedia.org/wiki/Capability-based_security -- Cap'n Proto isn't actually an RPC system, it's a capabilities framework. You can work with results without actually having the results, e.g. before the results exist.

> The 'cap' in Cap'n Proto is for https://en.wikipedia.org/wiki/Capability-based_security This seems to go completely unmentioned on the home page, other than the word “capability system” in the very first sentence. What does capability based security mean for a data interchange format? The notion hardly makes any sense to me. From the homepage: “Think JSON, except binary.” What would JSON look like with capability-b…

Cap'n Proto has a serialization layer and an RPC layer. The capability-based security part is mostly a feature of the RPC layer, not the serialization. The serialization does assist slightly in defining a way to encode remote references.

> This sounds exactly like promises

Yes, the API is Promise-based. Both Cap'n Proto and JavaScript Promises are inspired by the E programming language, which is a strict object-capability language.

Re: Cap'n Proto 0.9

#36

Post by setr »

edoceo wrote: post #19
setr wrote: post #14

Earlier quoted context omitted.

Having an opinion is not the same as having a good opinion. There’s a range of quality to the matter

The point is that "good" and "quality" is subjective and highly dependent on use-case.

And my point is that it’s not — the starting pieces may differ, and thus the conclusions, but there’s clearly a qualitative difference between the opinion of an expert, and the opinion of a novice. If only that the expert brings far more knowledge into his opinion than the novice. But also in that his opinion is of better foundation, of more supporting infrastructure, of more stable reasoning, and can in general be both better explained and better defended.

Opinions don’t exist in a void — they’re still the outcome of argument, and can easily be compared by that ruler.

And in this case, it’s trivial to imagine utterly terrible opinionated outcomes — use hyphen to represent addition, having functions like c’s get() (impossible to use correctly, and having defaults that are backwards in the common case.

It’s also trivial to imagine what a poorly reasoned opinion might look like: “ what's what opinions are - they necessarily must be wrong to some people. Otherwise, it'd just be called facts!”

Re: Cap'n Proto 0.9

#37

Post by kortex »

Communitivity wrote: post #32
moonchrome wrote: post #28

Earlier quoted context omitted.

If you're looking for a binary serialisation library that generates simpler/more readable code and doesn't do parsing look into flatbuffers. Going through generated protobuff code in . NET last time I used it was vomit inducing. Flatbuffers don't provide RPC AFAIK so not comparable with gRPC Capnproto tried to do too much with distributed objects and RPC, I was looking into it years ago but it still seems like the C+…

For your own sanity, please stay away from Flatbuffers. The key here is 'doesn't do parsing'. I used it, and wound up writing a ton of extract code to unpack things in the way I wanted. Behind the scenes everything in FlatBuffers is stored in a byte array or byte buffer. It can be made to work, but protobuffs worked better for me. Caveats: 1) I needed to work in C++ and Java 2) I was transporting serialized messages…

At one point I dug a bit into the python impl of Flatbuffers, and while I forget the exact details, I was struck by how inefficient it looked. Basically every accessor call requires parsing/casting (into python) bytes into objects, without any awareness of whether it had been parsed before.

Re: Cap'n Proto 0.9

#38

Post by heavenlyblue »

aseipp wrote: post #12
jchw wrote: post #8

Earlier quoted context omitted.

On paper I agree. However it does have a couple of problems: - It has yet to escape the ZeroVer versioning scheme and produce a “stable” API. - Maturity for languages other than C++ can be a bit spotty. - The RPC protocol is cool, but apparently most of it was never implemented. The C++ implementation only implements “level 1.” Cap’n Proto is undeniably cooler than Protobuf, although in practice I worry primarily abo…

It's fine if most implementations of RPC are Level 1, even the main C++ bindings; due to the design of the protocol there only needs to exist a single Level 4 implementation written in any language, and all other implementations can then piggyback on it for their own needs beyond Level 1 (so cap proxying, etc. all come "for free" once someone does that.) I've mentioned Level 4 support to Kenton a while back and the b…

Python implementation is super low quality.

A lot of their tests were checking for Exception raises and were basically testing AttributeError due to a change in interface instead of the initial error they were testing for.

Post reply on HN