max/nix-super
1
0
Fork 0
mirror of https://github.com/privatevoid-net/nix-super.git synced 2024-11-15 18:56:16 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions
nix-super/src/libstore/common-protocol.cc

98 lines
3 KiB
C++
Raw Normal View History

Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
#include "serialise.hh"
#include "path-with-outputs.hh"
#include "store-api.hh"
#include "build-result.hh"
#include "common-protocol.hh"
#include "common-protocol-impl.hh"
#include "archive.hh"
#include "derivations.hh"
#include <nlohmann/json.hpp>
namespace nix {
/* protocol-agnostic definitions */
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
std::string CommonProto::Serialise<std::string>::read(const StoreDirConfig & store, CommonProto::ReadConn conn)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
return readString(conn.from);
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
void CommonProto::Serialise<std::string>::write(const StoreDirConfig & store, CommonProto::WriteConn conn, const std::string & str)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
conn.to << str;
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
StorePath CommonProto::Serialise<StorePath>::read(const StoreDirConfig & store, CommonProto::ReadConn conn)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
return store.parseStorePath(readString(conn.from));
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
void CommonProto::Serialise<StorePath>::write(const StoreDirConfig & store, CommonProto::WriteConn conn, const StorePath & storePath)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
conn.to << store.printStorePath(storePath);
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
ContentAddress CommonProto::Serialise<ContentAddress>::read(const StoreDirConfig & store, CommonProto::ReadConn conn)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
return ContentAddress::parse(readString(conn.from));
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
void CommonProto::Serialise<ContentAddress>::write(const StoreDirConfig & store, CommonProto::WriteConn conn, const ContentAddress & ca)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
conn.to << renderContentAddress(ca);
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
Realisation CommonProto::Serialise<Realisation>::read(const StoreDirConfig & store, CommonProto::ReadConn conn)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
std::string rawInput = readString(conn.from);
return Realisation::fromJSON(
nlohmann::json::parse(rawInput),
"remote-protocol"
);
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
void CommonProto::Serialise<Realisation>::write(const StoreDirConfig & store, CommonProto::WriteConn conn, const Realisation & realisation)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
conn.to << realisation.toJSON().dump();
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
DrvOutput CommonProto::Serialise<DrvOutput>::read(const StoreDirConfig & store, CommonProto::ReadConn conn)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
return DrvOutput::parse(readString(conn.from));
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
void CommonProto::Serialise<DrvOutput>::write(const StoreDirConfig & store, CommonProto::WriteConn conn, const DrvOutput & drvOutput)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
conn.to << drvOutput.to_string();
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
std::optional<StorePath> CommonProto::Serialise<std::optional<StorePath>>::read(const StoreDirConfig & store, CommonProto::ReadConn conn)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
auto s = readString(conn.from);
return s == "" ? std::optional<StorePath> {} : store.parseStorePath(s);
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
void CommonProto::Serialise<std::optional<StorePath>>::write(const StoreDirConfig & store, CommonProto::WriteConn conn, const std::optional<StorePath> & storePathOpt)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
conn.to << (storePathOpt ? store.printStorePath(*storePathOpt) : "");
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
std::optional<ContentAddress> CommonProto::Serialise<std::optional<ContentAddress>>::read(const StoreDirConfig & store, CommonProto::ReadConn conn)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
return ContentAddress::parseOpt(readString(conn.from));
}
Restrict some code to `StoreDirConfig` - part of eval cache - part of derivations - derived path - store path with outputs - serializers
2022-03-18 17:35:45 +02:00
void CommonProto::Serialise<std::optional<ContentAddress>>::write(const StoreDirConfig & store, CommonProto::WriteConn conn, const std::optional<ContentAddress> & caOpt)
Factor out bits of the worker protocol to use elsewhere This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
2022-03-25 06:39:57 +02:00
{
conn.to << (caOpt ? renderContentAddress(*caOpt) : "");
}
}
Reference in a new issue Copy permalink