<humanetech>
I haven't had time to look deeper into Cap'n Proto since our call. One thing I must figure out, that worries me right now (but that may be fully lack of knowledge) is that AFAIU the RPC communication design is based on API contracts. It may be a Good Thing™ but it may also mean that that entails a less loosely coupled decentralized architecture compared to a pure Event Driven Architecture (where I must also not that currently AP isn't an
<humanetech>
EDA in that msgs can be both commands as well as events.. it isn't really clear).
<humanetech>
s/not/note/
<humanetech>
Instead of a system sending on the message bus ThisHappened and let anyone do their own domain logic based on that event, with RPC approach you are sending to a remote system foo(bar(x)) .. in other words you now need the remote contract have created a tight coupling.
<humanetech>
* Instead of a system sending on the message bus ThisHappened and let anyone do their own domain logic based on that event, with RPC approach you are sending to a remote system foo(bar(x)) .. in other words you now need the remote service contract, and you have created a tight coupling. A dependency on the remote system.
<humanetech>
(There is also a dependency in the case of the pure Event-driven approach.. after all, you need to interpret ThisHappened to know how to respond. So I don't know the full implications of either of these approaches. Though I have the gut feeliing that the pure event-driven leads to less coupling when comparing to compatibility to full remote API's)
<humanetech>
FYI We had [further discussion](https://matrix.to/#/!SakSkZqjzMsaPCVqlv:matrix.batsense.net/$XdDpfTyv2zaeWlgiA_PhxberRWhRUAkthfUIksHl_AQ?via=matrix.org&via=envs.net&via=t2bot.io) in the forge federation chatroom on this.
<kentonv>
humanetech, Cap'n Proto is intended as a low-level protocol for distributed systems. One-way messages are inherently unreliable unless you have a message queuing mechanism with storage and retries, which is a much higher-level thing.
<kentonv>
you could build such a system using Cap'n Proto
<kentonv>
but at Cap'n Proto's level, messages must have replies because if they don't, you have no way of knowing for sure if they were even delivered
<kentonv>
if I were building an event subscription system on top of Cap'n Proto, it would involve some sort of an interface where the publisher can push an event to a subscriber, and the subscriber must acknowledge successful receipt of the event. If it doesn't, the publisher waits for some amount of time and retries. If retries continue to fail, a human needs to be alerted.
<kentonv>
Note the subscriber might just store the event to disk and then acknowledge. It doesn't have to fully process the event synchronously, it just has to indicate that the message has been received.