On 12.4.12 18:43, Angela Schreiber wrote:
hi michael
On a related note: what kind of values do we want to expose from
oak-core? JSON like or JCR like?
i would prefer JCR like on the oak-API level and only have an
intermediate JSON serialization if there was remoting involved
in the communication between oak-jcr and oak-core (don't think
this is the standard setup).
the main reason for that is that we want to push the validation
and query into the oak-core layer. so imo the oak-core layer
needs to be aware of property types and therefore i don't
see an urgent need for extra conversion of values on that layer.
thinking for example of property definitions (nt),
value constraints, restrictions within access control entries
or specific queries.
Ok, makes sense. We need then
- Have a respective value entity on the oak-api. There is already the
CoreValue class which should somehow fit/be fitted into the picture.
- Update all places in the API where Scalar is used currently with the
new value representation.
- Still come up with a encoding into JSON. However since this is not
exposed through the oak-api we are more flexible here.
Could you come up with a draft for such a class/interface? That would
allow me to take the role of the API critic for once ;-)
Michael
kind regards
angela
Implementation wise, would that
en/decoding happen inside oak-jcr or oak-core?
Michael
[1]
http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/main/java/org/apache/jackrabbit/spi2microkernel/Values.java?view=markup
