Flatten Rust crates hierarchy

[tiziano88]

Currently some of our own Rust crates are under other folders, but crates actually all live in the same namespace, so this level of nesting is usually more confusing than helpful, since e.g. it is not reflected in the name of the crate or anywhere else.

I think it would be more idiomatic to have all the crates in the workspace at the same level, and use crate name prefixes to group similar crates (e.g. oak_example_*).

[conradgrobler]

We should probably decide on an overall approach for all the content on the site. If we move everything, including e.g. java code to the top level it might become difficult to find anything an navigate.

Also, it might be useful to differentiate between library crates, which might at some point be published to crates.io and binary crates. This would be especially useful if we lean more strongly into the idea of having a distinct crate for every combination of runtime + plugins + platform.

[tiziano88]

Those are all good things, I just don't think they should be expressed by nesting crates under specific paths, which gives the impression of a nested hierarchy of crates, while crates all exist in a flat namespace (and so for instance ideally will probably require finding unique names, even if we decide not to publish them); e.g. for lib vs bin crates, the Cargo.toml file is the source of truth; if we want to keep differentiating experimental from "ready" crates, we should probably do that by documenting it explicitly anyways, etc.

re: Java vs Rust vs other languages, perhaps we should split those at top level? e.g. have rust and java folders in the root of the repo, instead of, say, nesting the Java remote attestation logic under the Rust remote attestation crate. But I'm also not sure that's ideal.

[conradgrobler]

re: Java vs Rust vs other languages, perhaps we should split those at top level? e.g. have rust and java folders in the root of the repo, instead of, say, nesting the Java remote attestation logic under the Rust remote attestation crate. But I'm also not sure that's ideal.

Yes, it is not ideal, but I also cannot really think of any better approaches.

[tiziano88]

After some more thought, I think we should split things by language first (similar to https://github.com/google/tink ). Though in the short term we can just assume that everything in the root is Rust, and just create top-level folders for non-rust languages (i.e. java and cc), and move the corresponding code under those.

For the Rust crates, we should flatten them so they are all at the same level in the root, and each of them should be named exactly as the folder that contains it.

Additionally, even though we are not planning to publish most of them to crates.io, it would be good if all our crates had globally unique names, so I suggest we at least prefix all of them with oak_ if they are not already.

e.g. https://github.com/project-oak/oak/blob/1b55c30f20edb8fcae78990dd4585975371c43ae/remote_attestation/rust/Cargo.toml#L2 should be moved to a folder called oak_remote_attestation, without the intermediate rust folder, and the java folder should be moved to top-level.

cc @marush-ka

[tiziano88]

To start with, I suggest creating a top-level java folder, and move into it all the java code, namely:

• https://github.com/project-oak/oak/tree/main/remote_attestation/java
• https://github.com/project-oak/oak/tree/main/oak_functions/client/java

Not sure about https://github.com/project-oak/oak/tree/main/oak_functions/examples/weather_lookup/client/java though, since that's kind of part of a specific example; let's leave it alone for the time being and get back to it after the initial move.

[ipetr0v]

Is it possible that we'll end up with 30+ different crates in the same directory? We probably could think about at least a small amount of top level crates:

• oak_base
  • kernel
  • kernel_loader
• oak_functions
  • runtime
  • client
• trusted_shuffler
  • runtime
  • client

Or vice versa:

• restricted_kernel
• runtime
  • oak_functions
  • trusted_shuffler
• client
  • grpc_unary
  • grpc_streaming

[ipetr0v]

I.e. I think it's ok to have a hierarchy even though crates are all at the same level. Since it's just for convenience of use and reading the code.

[tiziano88]

I think this was sufficiently flattened, though there are still some exceptions, but we can track those separately.