I've just encountered a situation where I'd like to in which I like to validate that the recipe_ah of an SignedEvmSigningOffer points to a Recipe 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 records EntryType instead.
This isn't possible with the current crate structure because the EntryTypes and UnitEntryTypes 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 #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.
I've just encountered a situation where I'd like to in which I like to validate that the
recipe_ahof anSignedEvmSigningOfferpoints to aReciperecord. 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 recordsEntryTypeinstead.This isn't possible with the current crate structure because the
EntryTypesandUnitEntryTypesenum 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 #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.