- 11 Jan, 2018 1 commit
-
-
Kenton Varda authored
@kloepper pointed out a while back that every compiler you've ever heard of supports this. Plus, it's more concise, it's not prone to copy-paste errors, and it looks nicer. At the time I wanted to remain consistent and I didn't feel like spending the time to update all my existing code. But, every time I've added a new header since I've cursed the include guard, so I finally broke down and changed it.
-
- 03 Jan, 2018 1 commit
-
-
Kenton Varda authored
-
- 19 Sep, 2017 1 commit
-
-
Kenton Varda authored
-
- 02 Oct, 2016 1 commit
-
-
David Renshaw authored
-
- 18 Jun, 2016 1 commit
-
-
David Renshaw authored
-
- 17 Jun, 2016 1 commit
-
-
Kenton Varda authored
This is blunt: A peer can choose to stop reading new messages from a connection whenever the calls in-flight cross a certain threshold. This is needed in Sandstorm to prevent errant (or malicious) apps from consuming excessive RAM in other parts of the system by flooding them with calls.
-
- 02 Apr, 2016 1 commit
-
-
Liam Staskawicz authored
fixes #304
-
- 03 Jul, 2015 1 commit
-
-
Kenton Varda authored
**The problem** The methods MessageReader::initCapTable() and MessageBuilder::getCapTable() always felt rather hacky. initCapTable() in particular feels like something that should be handled by the constructor. However, in practice, the cap table is often initialized based on a table encoded within the message itself. That is, an RPC message contains a "payload" which includes both the application-level message structure and a table of capabilities. The cap table has to be processed first, then initCapTable() is called on the overall message, before the application structure can safely be read. The really weird part about this is that even though the cap table only applies to one branch of the message (the payload), it is set on the *whole* MessageReader. This implies, for example, that it would be impossible to have a message that contains multiple payloads. We haven't had any need for such a thing, but an implemnetation that has such artificial limitations feels very wrong. MessageBuilder has similar issues going in the opposite direction. All of this ugliness potentially gets worse when we introduce "membranes". We want a way to intercept capabilities as they are being read from or written to an RPC payload. Currently, the only plausible way to do that is, again, to apply a transformation to all capabilities in the message. In practice it seems like this would work out OK, but it again feels wrong -- we really want to take a single Reader or Builder and "wrap" it so that transformations are applied on capabilities read/written through it. **The solution** This change fixes the problem by adding a new pointer to each struct/list Reader/Builder that tracks the current cap table. So, now a Reader or Builder for a particular sub-object can be "imbued" with a cap table without affecting any other existing Readers/Builders pointing into the same message. The cap table is inherited by child Readers/Builders obtained through the original one. This approach matches up nicely with membranes, which should make their implementation nice and clean. This change unfortunately means that Readers and Builders are now bigger, possibly with some performance impact.
-
- 06 May, 2015 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
Add ability to construct a new bootstrap capability for each connecting client based on their authenticated VatId.
-
- 19 Feb, 2015 1 commit
-
-
Kenton Varda authored
-
- 14 Dec, 2014 1 commit
-
-
Kenton Varda authored
I've added -Wextra as well as removed some of the -Wno-* flags and fixed issues in the code. Also fixed the cmake build to put user-defined flags after default flags so that they can be overridden.
-
- 10 Dec, 2014 1 commit
-
-
Kenton Varda authored
-
- 22 Nov, 2014 1 commit
-
-
Kenton Varda authored
This prevents the compiler from reporting warnings in these headers while compiling application code. Hopefully this will stem the never-ending stream of complaints from people who enable pedantic warnings.
-
- 13 Nov, 2014 1 commit
-
-
Kenton Varda authored
-
- 09 Nov, 2014 1 commit
-
-
Kenton Varda authored
-
- 04 Nov, 2014 1 commit
-
-
Kenton Varda authored
The 'objectId' field is now deprecated. Long-term, each vat will export no more than one "bootstrap interface" which can be obtained via 'Bootstrap'. Restoring SturdyRefs will be accomplished through higher-level interfaces specific to the VatNetwork in use. See comments for 'Bootstrap' in rpc.capnp for more discussion.
-
- 20 Jun, 2014 1 commit
-
-
Kenton Varda authored
For portions currently copyright by Kenton (most of it), transfer copyright to Sandstorm Development Group, Inc. (Kenton's company). The license change is practically meaningless, as MIT and BSD 2-clause are legally equivalent. However, the BSD 2-clause license is sometimes confused for its ugly siblings, BSD 3-clause and BSD 4-clause. The MIT license is more immediately recognizeable for what it is. Rémy Blank and Jason Choy (the two non-trivial contributors) are on record as approving this change: https://groups.google.com/d/msg/capnproto/xXDd2HUOCcc/gbe_COIuXKYJ
-
- 22 Dec, 2013 1 commit
-
-
Kenton Varda authored
-
- 11 Dec, 2013 1 commit
-
-
Kenton Varda authored
Eliminate the concept of imbuing messages in favor of the simpler concept of setting a cap table directly on MessageReader / getting one from MessageBuilder. This eliminates capability-context entirely. This was made possible by the earlier change which moved capabilities to a separate table rather than storing CapDescriptors inline, but I didn't realize it at the time.
-
- 05 Dec, 2013 1 commit
-
-
Kenton Varda authored
-
- 04 Dec, 2013 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
Overhaul the way EventLoop is specialized so that it's possible to hook up to an existing event loop infrastructure that is not KJ-aware. This also makes the async IO API more dependency-injection-friendly.
-
- 30 Nov, 2013 1 commit
-
-
Kenton Varda authored
-
- 28 Nov, 2013 1 commit
-
-
Kenton Varda authored
Revamp concurrency model, part 1: EventLoop no longer allows cross-thread event queuing, simplifying many things. Capability clients are no longer thread-safe, so they don't have to be so const. In the future, explicit ways to communicate between threads will be re-added, but threads will be treated more like separate vats that just happen to have a particularly fat pipe. Upcoming: Remove mutexes.
-
- 18 Nov, 2013 1 commit
-
-
Kenton Varda authored
-
- 14 Nov, 2013 2 commits
-
-
Kenton Varda authored
In RPC protocol, rename request -> params, answer -> results. Also fix up Join stuff in rpc-twoparty.capnp, because it was sort of wrong.
-
Kenton Varda authored
-
- 11 Nov, 2013 1 commit
-
-
Kenton Varda authored
-
- 08 Nov, 2013 1 commit
-
-
Kenton Varda authored
Implement two-party network. The first RPC call over a socket took place at 2013-11-08 14:46:43 -0800 and completed successfully.
-
- 31 Oct, 2013 1 commit
-
-
Kenton Varda authored
-
- 26 Oct, 2013 1 commit
-
-
Kenton Varda authored
-
- 17 Oct, 2013 1 commit
-
-
Kenton Varda authored
-