Stuff like blockchain, client, snapshot, common types, executive/externalities can basically all be their own crates.
Hi @rphmeier .
I want to take a crack at this, but I am hitting issues.
The modules in ethcore use each other, so making a crate for executive/externalities/types/snapshot or most of the modules would result in circular dependencies that cargo forbids.
I have made a matrix of dependencies per module, see https://gist.github.com/nicolasochem/6a813b2cd1af3c7e9837d3b37d6c9b75
Looking at this, it is not going to be possible to simply separate the modules by moving files around. New abstractions are needed. Is my assumption correct ?
it's mostly correct. this is a fairly big job.
@nicolasochem That's right. As Gav says, making this change will probably require decent familiarity with the internal workings of Parity.
The types module is largely obsolete with the advent of procedural macros for serde derivation (we can strip out the unused IPC stuff for the time being until the codegen is rewritten as a macro). The way I'd start to take a crack at this would go something like this:
types modules back to where they largely belong.ethereum-core-types crate with Header, Block, and Transaction typesengine crate which defines the engines (later on we'll split the implementations out). needs to abstract over something more general than ExecutedBlock since we want to have State processing higher up as well.evm should be mostly painless.ethcore would be client, blockchain, miner, and snapshot. Not sure of the best way to take those out just yet but they are definitely some of the most "entangled" pieces.Btw, types in types::* are exactly collection of types that cross api boundaries between main components (sync, client, probably miner)
So it may worth splitting them into separate crate roughly as they are present now in the said module.
Most helpful comment
Hi @rphmeier .
I want to take a crack at this, but I am hitting issues.
The modules in ethcore use each other, so making a crate for executive/externalities/types/snapshot or most of the modules would result in circular dependencies that cargo forbids.
I have made a matrix of dependencies per module, see https://gist.github.com/nicolasochem/6a813b2cd1af3c7e9837d3b37d6c9b75
Looking at this, it is not going to be possible to simply separate the modules by moving files around. New abstractions are needed. Is my assumption correct ?