Junha Yang(양준하)
Junha Yang(양준하)
Current Foundry's project structure is somewhat tangled. I suggest following new structure. 1. We have a separate repo for types/traits/utilities widely used in the host and modules. (Let's say `foundry-suite`)...
actix has the functionality for that. https://docs.rs/actix-web/3.0.2/actix_web/struct.HttpServer.html#method.bind_uds
## Background Light clients (both standalone and ICS) utilize the concept of 'Update header', which is a set of data that is enough to update a light client's best header....
See https://github.com/CodeChain-io/foundry/issues/112 It is not necessary for the ICS, and thus has no high priority over that.
Our RLP heavily depends on Ethereum's implementation(https://github.com/paritytech/rlp). They provide some procedural macros that generate encoding/decoding code for basic objects, but it lacks of many details and functionality. Though it helps...
It should always be imported. The policy to handle a not imported case is not decided
Since rust doesn't support async trait method, this will be a really exceptional interface.
Most of errors that caused by unexpected behavior of the other side's RTO port will just lead to panic. However, especially in Foundry context, the other port might have been...