Split Lucid into server and cli binaries

[shuni64]

This cleans up the server code by removing most of the the cli handling, leaving only the init subcommand. All other functionality has to be implemented as an API that the client can access.

The cli isn't interactive like the previous cli subcommand, but it's structured in a way that it shouldn't become a problem and will allow it to easily be used with scripts.

This also includes switching to alpha versions of various crates because of a ring-asm version conflict, which in return requires using the new async-await syntax. As a result Rust 1.39 has to be the new minimum supported version.

I would appreciate feedback on this.

[imclint21]

Awesome works, I just clone your repo and build it, I think my morning mistakes will make some problems for merging haha!

[shuni64]

futures previously provided the Future trait for other crates to build on, but it's in the standard library now, so we don't have to use that crate directly.

tokio provides the runtime for the futures to run in and hyper doesn't seem to re-export the necessary macro, so we have to use it if we want to use multiple threads (although we could use another executor, I'm not aware of a better one existing).

[imclint21]

Hi,

Firstly, I really enjoy your modifications, adding await/async, cleanup, etc.

From my side, I'm against a binary split, I want to keep lucid.exe or lucid as binary, but like @Slals said it's essential to split the code into many projects as you do!

I would like to keep your changes but have only 1 binary after the build.

Best regards

[imclint21]

Hi @CephalonRho,

I'll explain to you, why I want to keep into one output binary!

Basically I'd like to do like HashiCorp software, here you can take a look at Vault, that it's a HashiCorp program.

By the way, we can remove the CLI part from the binary and make a wholly separated project.

Cheers

[Slals]

Hi guys,

I haven't reviewed the code yet. Project structure wise, we want to have things splitted such has a crate (repo) for the core, another one for the CLI / RPC, another one for HTTP, etc.

Doing this won't stop us to package everything into one bin. So we would be able to do like Vault and gaining advantage of multiple projects. Especially because the core lib will be critical while the CLI not much. We want the make threw reviews on the core and we don't want any burden such as the CLI inside some commits about the core.

[shuni64]

I still don't see much of a benefit in keeping a single binary, but dividing Lucid into multiple library packages and a single binary package is fine too. It might actually be better since it allows decoupling more parts than just the cli.

Not sure if there should be separate repositories for every package, using a cargo workspace in this repository would make it a lot easier to change multiple parts of Lucid at the same time.

We've come to a conclusion that doesn't match the purpose of this PR anymore, so I'll close it.