aboutsummaryrefslogtreecommitdiff
path: root/src/libstore/worker-protocol.cc
AgeCommit message (Collapse)Author
2023-06-19Create `worker_proto::{Read,Write}Conn`John Ericson
Pass this around instead of `Source &` and `Sink &` directly. This will give us something to put the protocol version on once the time comes. To do this ergonomically, we need to expose `RemoteStore::Connection`, so do that too. Give it some more API docs while we are at it.
2023-06-19Put worker protocol items inside a `WorkerProto` structJohn Ericson
See API docs on that struct for why. The pasing as as template argument doesn't yet happen in that commit, but will instead happen in later commit. Also make `WorkerOp` (now `Op`) and enum struct. This led us to catch that two operations were not handled! Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2023-06-19Split out worker protocol template definitions from declarationsJohn Ericson
This is generally a fine practice: Putting implementations in headers makes them harder to read and slows compilation. Unfortunately it is necessary for templates, but we can ameliorate that by putting them in a separate header. Only files which need to instantiate those templates will need to include the header with the implementation; the rest can just include the declaration. This is now documenting in the contributing guide. Also, it just happens that these polymorphic serializers are the protocol agnostic ones. (Worker and serve protocol have the same logic for these container types.) This means by doing this general template cleanup, we are also getting a head start on better indicating which code is protocol-specific and which code is shared between protocols.
2023-05-17Revert "Revert "Use template structs instead of phantoms""John Ericson
This is the more typically way to do [Argument-dependent lookup](https://en.cppreference.com/w/cpp/language/adl)-leveraging generic serializers in C++. It makes the relationship between the `read` and `write` methods more clear and rigorous, and also looks more familiar to users coming from other languages that do not have C++'s libertine ad-hoc overloading. I am returning to this because during the review in https://github.com/NixOS/nix/pull/6223, it came up as something that would make the code easier to read --- easier today hopefully already, but definitely easier if we were have multiple codified protocols with code sharing between them as that PR seeks to accomplish. If I recall correctly, the main criticism of this the first time around (in 2020) was that having to specify the type when writing, e.g. `WorkerProto<MyType>::write`, was too verbose and cumbersome. This is now addressed with the `workerProtoWrite` wrapper function. This method is also the way `nlohmann::json`, which we have used for a number of years now, does its serializers, for what its worth. This reverts commit 45a0ed82f089158a79c8c25ef844c55e4a74fc35. That commit in turn reverted 9ab07e99f527d1fa3adfa02839da477a1528d64b.
2023-05-17Move `worker_proto` defs out of `remote-store.cc` to own fileJohn Ericson
These items are not templates, and they declared in `worker-protocol.hh`; therefore they should live in a `worker-protocol.cc`. Anything else needlessly diverges from convention. After all, it is not like this code is only used in `remote-store.cc`; it is also used in `daemon.cc`. There is no good reason to place it with the client implementation or the server implementation when it used equally by both.