Profile cover photo
Profile photo
Charles Strahan
Charles's posts

Post has attachment
Charles Strahan commented on a post on Blogger.
(Note that I'm not the author of Cap'n Proto, just a person who appreciates the design, and the author of a nascent implementation for Haskell.)

>> Immediately after each struct are a series of "fix-ups" or "field population instructions" that are basically a sequence of (field number, data type, data length, data) tuples.

Without fixed offsets, you'll have to pay for deserializing everything up front. With Cap'n Proto, you only pay for what you use. In something like what you describe, you'll have to hydrate a bunch of objects, which requires twice as much effort: the reads/writes from/to the buffer, and the reads/writes to the fields of your objects/structs/whatever your language decides to call them. With Cap'n Proto, the generated code directly read/writes from/to the buffer - half as much IO.

>> Basically if a programming language does not use raw struct layout in memory, then it won't be able to take advantage of the Cap'n Proto styled encoding

This is not true. In fact, Cap'n Proto's C++ implementation does not use struct layout, it generates classes that wrap a pointer and provides getters and setters. If your language supports arrays and a means of pulling-out/pushing-in primitives (ints, floats, strings, etc), you're set. That means Cap'n Proto can easily be implemented in C/C++, Rust, Python, JavaScript (see ArrayBuffer), Java (see ByteBuffer), C#, Haskell (I'm writing an implementation right now), etc - practically any relatively mainstream language you can think of.

>> and having a compact wire format is probably better.

What you describe would actually require more data on the wire - you include type metadata and field number, which Cap'n Proto does not. After packing (, Cap'n Proto messages will be much, much smaller.

Post has attachment
Charles Strahan commented on a post on Blogger.
Looks neat, but I'm not having any luck finding the source code. It looks like the code was previously available on Launchpad, but no longer.

What's the deal? Is Canonical thinking about keeping this closed source? Is there some embarrassment about the code quality? Seems strange that it would just disappear. It's a shame, because I'd love to play around with it.

Post has attachment
An excellent presentation on Shadow DOM.
Wait while more posts are being loaded