Open 8e8b2c opened 3 months ago
Partially addressed by this spike: https://github.com/holochain-open-dev/holoom/pull/98
While above solution makes entry defs injectable, it doesn't yet describe how zomes would be made aware of sibling zome indices. That might require some compile time variables.
On the other hand, I haven't yet encountered a strong motivation for separating features into zomes, other than for the sake of making code more modular (which we've achieved anyway).
I've just encountered a situation where I'd like to in which I like to validate that the
recipe_ah
of anSignedEvmSigningOffer
points to aRecipe
record. An imprecise way in which to do this is to attempt to deserialise the entry into the structure of a record. This approach is probably adequate but not flawless in general because the and struct type may overlap sufficiently to give a false positive. Therefore I would like to make a comparison on the recordsEntryType
instead.This isn't possible with the current crate structure because the
EntryTypes
andUnitEntryTypes
enum are declared in the integrity crate, which is a dependant of the validation crate.At the same time, we're also discussing separating differing functionality into zomes (see https://github.com/holochain-open-dev/holoom/issues/4). Integrity zomes cannot specify each other as dependencies, therefore we should devise a strategy that allows the enums to be shared between zomes without the zomes beings interdependent.