In D5706#170542, @ashoat wrote:

Not clear if that stuff will be handled in Rust or C++ in the future... but at the same time don't want to block this diff on figuring that out. I think it's fine either way – if we leave it in now, we just have to remember to remove it later when we introduce a hypothetical Rust replacement for that code. On the other hand, if we remove it now we'll have to remember that we wrote this already and don't need to write it again

In D5706#170355, @tomek wrote:

GlobalNetworkSingleton shouldn't be deleted https://linear.app/comm/issue/ENG-1334#comment-673e1516.

GlobalNetworkSingleton.cpp - The file will be completely changed, we don't want to store an empty file;

Why is that? Both scheduleOrRun and enableMultithreading methods are still relevant.

In D5714#170536, @ashoat wrote:

Can you please do more research to figure out everything that can be deleted here? A single git grep mark-generated popped up two more places
Delete mark-generated.sh as well

Removing of the codegen-grpc from shared and mark-generated.

Removing linter spaces from CMake files.

Regenerating jsi.

Rebasing on master and fixing a nit.

Rebasing on master.

Removing Podfile from the keyserver's Docker file.

Rebasing.

Rebasing on parents and master changes.

Rebasing on parents and master changes.

Rebasing.

Rebasing on parents changes.

Rebasing on parent changes.

Rebasing on parent and master changes.

Adding of the internal error to the client in case of the error on updating the token in a database.
Rebasing and fix merge conflicts.

Rebase and resolve merge conflict.

Fix merging.

Rebasing on master and parents changes.

Fix merging.

Resolving merge.

Rebasing and fixing merge.

Landing this diff because Jon and Tomek accepted it, and the blocking reviewer (Tomek) was removed accidentally.

Rebasing on the master and parent diffs changes.

Fixing enum discriminant number for the KEYSERVER.

Rebase and merge.

Updating on comments.

In D5640#167758, @jon wrote:

I would like to see configuration done in rust, as argument reading + argument validation is a bit nicer using crates like clap. But as a transition, I think this is fine.

From an architectural standpoint, I don't think the business logic should really be aware of whether it's running in a sandbox. We should be passing it other values (e.g. dev rabbitmq endpoints) which make the environment a sandbox.

In D5684#168833, @ashoat wrote:

I imagine we'll want to keep something like GRPCStreamHostObject around in the future... we need a JSI class that can replace WebSocket, and since it's JSI it will need to be implemented in C++.

That said, the new GRPCStreamHostObject will need to interface with Rust / tonic behind the scenes.

I'm not sure if there's some way to keep the current GRPCStreamHostObject in the codebase. If we definitely need to remove it now, I guess we can always check git history when we're bringing it back.

Fixing native builds.

Fixing building error.

Removing of the old structs from the protofile.

Removing a new line.

Changes to use enum for the gRPC status codes.

Adding of the DeviceTypes enum. Change to use stoul to convert from the database's integer to device type.