Open lght opened 6 years ago
@0x7CFE is doing an amazing work on the ethcore refactoring in https://github.com/paritytech/parity/pull/7038 We need to at least coordinate feature splitting with him (and in the best case he will also help us with determining the scope of those features, or even reduce the amount of external dependencies ethcore has at all).
That work is great, will be happy to coordinate with @0x7CFE on strategy. ~Think it may still be safe to get started on~ Will hold for now on creating a new / splitting off unnecessary components from ethcore
.
FYI, ethcore-light
already exists and stores the light client database schema, import logic, and network code.
I think the real question is what we want to achieve, we have couple of goals, but with a completely different scopes and timelines. Main pain points currently: long compilation, large repo to fetch, no way to release to crates.io.
Solaris is using small crates referenced from crates.io
- fast compilation speed, no dependency on Parity, Solaris can be released to crates.io
.
Solaris is using medium crates referenced from Parity repository or smaller repositories. - fast compilation speed, no need to download the whole Parity repo while building.
Improving compilation time, but getting rid of unnecessary stuff in ethcore
crate:
ethcore-light already exists and stores the light client database schema, import logic, and network code
@rphmeier, I did not realize this was a thing. Perhaps a new name entirely for the components we need would be better than a confusing modification of ethcore-something
?
Improving compilation time, but getting rid of unnecessary stuff in ethcore crate
@tomusdrw, compilation time was my main pain point. Will start working on stripping out the unnecessary parts of ethcore
. The mid-term solution should be possible, and much easier, once @0x7CFE finishes the Client
refactor.
Since ethcore-light
is already close to what we want in the short term, will start there for the minimization effort. Working title of ethcore-mini
.
@tomusdrw is there something that comes to mind that would require little/medium work but should give us a big reduction in ethabi compilation time?
@snd we are considering extracting some crate to a separate repo: paritytech/common
, might be worth to include evm
and test_client
there as well, cc @dvdplm
Definitely a huge gain would be to get rid of rocksdb
dependency (if not done already), the easiest way would be to have it feature-gated.
ethcore
is at the heart of both Parity and Solaris. It is also the largest single dependency required by Solaris.This issue is to track discussion and strategy for minimizing
ethcore
into a manageable, modular crate. The goal of minimizing / splitting apartethcore
is to decrease compilation times, and enable other tools to select whichethcore
components they would like to use.After discussion with @tomusdrw and @kirushik, there are a few different strategies to pursue:
ethcore
--no-default
when building Solarisethcore
modules into sub-cratesethcore-light
with only necessary featuresThe above ideas are starting points, and subject to change. Personally, would prefer the last option of creating a new
ethcore-light
, having the long-term vision of replacing the currentethcore
with a sub-crate architecture.Refactoring such a critical piece of Parity must obviously be done with care, and starting a new
ethcore-light
greatly reduces the impact to / from other Parity components while it's under development.