jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: oak api : initial draft
Date Thu, 29 Mar 2012 09:48:34 GMT

>>>- Having NodeState and NodeBuilder in the oak-core API currently
>>> 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.


View raw message