This crate is currently not linked in any way to key-server folder (see #4 for explanation). Some notes on every extracted file and why it has been extracted:
acl_storage.rs: we'll need to have different implementations for all supported blockchains => it isn't a part of a key-server. It also has in-memory implementation, which could be used in test mode (we have had this in parity-ethereum) or in tests;
error.rs: to link different components together;
executor.rs: original idea was to get rid of tokio, but it is too much refactoring for now. So there's a trait Executor for pieces of code that are tokio-agnostic and implementation (type Tokio*) based on tokio runtime that is compatible both with tokio 0.1 and 0.2 (network code in key-server still uses 0.1, and new http-service uses 0.2). I'll file an issue later about possible migration to single tokio, or tokio-agnostic runtime;
key_server_key_pair.rs: in parity-ethereum we have had two implementations - one has been based on accounts secure storage and the second one has been in-memory. The latter one is introduced in this file (InMemoryKeyServerKeyPair), and the former should be implemented in final binaries;
key_server_set.rs: this depends on blockchain => shouldn't be a part of key-server. In-memory implementation (what has been called fixed key server set is also here - InMemoryKeyServerSet);
key_server.rs: is the key server API. It has changed a bit, since different endpoints (services) may have different responses formats (i.e. in HTTP service we may want to encrypt data, while other endpoints may return data unencrypted);
key_storage.rs: some binaries may have their own storages. In-memory storage (InMemoryKeyStorage) is also here. Not sure about rocksdb-based storage - whether we need separate crate for that, or it could be left in key-server. Will need to think on that;
requester.rs: is a part of key server API;
serialization.rs: questionable, because we only require this for http-service and key-server;
service.rs: defines traits and enums required to implement SS service.
This crate is currently not linked in any way to
key-serverfolder (see #4 for explanation). Some notes on every extracted file and why it has been extracted:-server. It also has in-memory implementation, which could be used in test mode (we have had this in parity-ethereum) or in tests;trait Executorfor pieces of code that are tokio-agnostic and implementation (type Tokio*) based on tokio runtime that is compatible both with tokio 0.1 and 0.2 (network code inkey-serverstill uses 0.1, and newhttp-serviceuses 0.2). I'll file an issue later about possible migration to single tokio, or tokio-agnostic runtime;InMemoryKeyServerKeyPair), and the former should be implemented in final binaries;key-server. In-memory implementation (what has been called fixed key server set is also here -InMemoryKeyServerSet);InMemoryKeyStorage) is also here. Not sure about rocksdb-based storage - whether we need separate crate for that, or it could be left inkey-server. Will need to think on that;http-serviceandkey-server;