E3Router was designed for a situation where we need to assemble objects on the fly and cache their dependencies whilst forwarding and buffering messages to downstream components as well as hydrate components from disk cache in the event of shutdown. It is a complex part of the ciphernode stack.
With the advent of Threshold BFV and Multithread having FHE as a dependency is not necessary and the only dependency left is E3Meta which may not justify the complexity
I believe we might be able to streamline and simply some parts of hydration and remove the dependency system
Also from_snapshot might be able to take an optional snapshot and be the only way to create objects which should lead to deduplication.
We don't need the dependency functionality once we move to TrBFV so it makes sense to rip that out after we ship TrBFV which is when we should be looking at this issue.
If we require dependencies in the future it may make more sense to register a constructor with the context so that if an extension requires a dependency that dependency is constructed based on E3Context information as required.
We should review the design and adjust as needed
E3Router was designed for a situation where we need to assemble objects on the fly and cache their dependencies whilst forwarding and buffering messages to downstream components as well as hydrate components from disk cache in the event of shutdown. It is a complex part of the ciphernode stack.
With the advent of Threshold BFV and Multithread having FHE as a dependency is not necessary and the only dependency left is E3Meta which may not justify the complexity
I believe we might be able to streamline and simply some parts of hydration and remove the dependency system
Also from_snapshot might be able to take an optional snapshot and be the only way to create objects which should lead to deduplication.
We don't need the dependency functionality once we move to TrBFV so it makes sense to rip that out after we ship TrBFV which is when we should be looking at this issue.
If we require dependencies in the future it may make more sense to register a constructor with the context so that if an extension requires a dependency that dependency is constructed based on E3Context information as required.
We should review the design and adjust as needed