Hi, >>>- Having NodeState and NodeBuilder in the oak-core API currently >>>introduces >>> a dependency on oak-mk for clients of that API. >> >> Right. This would be a non-issue if we hadn't split oak-core apart... > >imo we need a separate api at the oak-core (SPI) level without >any dependency to MK. >it's a different level of abstraction [...] from my point of view >the MK is the replacement for the former persistence layer just >being in charge of the storage.
I agree with Angela here. For example, PropertyState (used in NodeState) currently doesn't know the JCR property type. Of course we can change that to include that information (an integer for example), but this information shouldn't concern the MK layer. It would add concerns of oak-jcr into the storage level, which feels illogical to me. Also, PropertyState currently has a method "String getEncodedValue()" which returns the JSON encoded value. This is something that shouldn't concern oak-jcr. But it's not such a big problem as to expose oak-jcr concerns in oak-mk. I kind of see the advantage to only have one NodeState / NodeBuilder abstraction, but I'm not sure if that's the right solution. A workaround would be to use generics: NodeState<T> / NodeBuilder<T> / PropertyState<T>, and then in oak-mk use PropertyState<Json>. And in oak-jcr and oak-core use PropertyState<CoreValue> (and/or possibly use PropertyState<Value> in oak-jcr). >>Anyway, I'd rather keep the oak-mk reference as is for now [...] Yes, we need to come up with an abstraction. Regards, Thomas
