| 13 Mar 2026 |
 flokli | and it's working fine-ish? | 14:42:55 |
 piegames | Or am I misremembering something here | 14:43:02 |
| flokli | there's a few known perf issues due to how to the blob/chunk substitution doing more roundtrips than necessary, but that's more of a "we need to refactor the code at some point" than a gRPC-issue per se | 14:44:00 |
 griff | And as long as the data flowing is compatible making a converter from gRPC to Capnp or even to old shitty daemon protocol should be possible | 14:45:51 |
| flokli | we picked gRPC over captnproto because it's generally better supported across various programming languages, and it felt like captnproto still requires you to be on your own for a lot of things. | 14:45:54 |
| flokli | That being said, it's just another implementation of our traits, you can also talk another protocol. | 14:46:14 |
| flokli | I don't know how much captnproto forces you to model your application logic to its needs, if you make use of some of the more fancy stuff. We don't use any of these currently. | 14:47:05 |
| griff | it doesn't force your application logic to do anything. gRPC does that more in that it is entirely request/response based and you can't send an interface to be called back to the remote | 14:52:23 |
| flokli | ok, what i meant to say is that right now all our traits are request/response based. | 14:55:25 |
| flokli | so using either captnproto or grpc is just a matter of implementing that trait surface. | 14:56:13 |
 Lisanna | I was mixing up gRPC with Capn Proto, the only reason I mentioned gRPC is because that's what I thought Lix was going with | 14:58:37 |
| Lisanna | we may not touch the protocol implementation at all and instead focus on providing an extensible API in libnix-store | 14:59:23 |
