OCapN, Interoperable Capabilities over the Network

for example timeouts in ibc, client cannot timeout if server is dead for example. ibc goes hand in hand with identity and sagas.

------------

I'll say a bit about "distributed garbage collection". I'm not caught up on what, exactly, the ocapn people mean here. E always advertised support for "distributed acyclic garbage collection", which in practice meant reference counting. Cap'n Proto also implements reference counting in exactly the same way. But I personally wouldn't call it "garbage collection" if it can't collect cycles. Moreover, Cap'n Proto applications commonly expect deterministic destruction when references are dropped -- they wouldn't play well with GCs that might arbitrarily delay collection.

My personal take is that distributed GC is simply not feasible. Garbage collection algorithms heavily lean on heuristics and amortization to achieve any kind of performance. In particular, most GCs will only actually execute when they detect "memory pressure", i.e., that the system is in need of freeing up some memory. If the system doesn't need memory, why waste time finding some? However, in a distributed system, it can easily be the case that the local system has plenty of memory, but is holding on to a reference to a remote object living on a system that does need memory. The reference may no longer be reachable. But, the local GC isn't going to run because it doesn't perceive a need. Meanwhile, the remote system has no way to know that the object it is hosting could be collected.

To solve problems like this, you cannot just have each machine running its own local GC, you must have a single distributed GC that can respond to memory pressure anywhere by triggering sweeps of the entire distributed object graph. This seems extremely difficult to design, far more so if the systems involved do not trust each other.

Maybe it's possible, but certainly there's quite a lot of research needed, and last I knew the ocapn people hadn't actually demonstrated anything that works. But my personal take is that GC in general is a terrible fit for systems programming, because it is so bad at handling any kind of external resource, which is what systems programming is all about. Cap'n Proto is unlikely to support anything more than reference counting.

Unfortunately with Ian passing away, the Cap'n Proto side isn't seeing a ton of attention, though several involved parties are familiar with Cap'n Proto and reference it in discussions with regards to maintaining similarities and hopefully bridge-ability.