hi
On a related note: what kind of values do we want to expose from oak-core?
JSON like or JCR like?
I'd ideally like to keep it JSON-like so we can easily implement a
JavaScript-friendly HTTP mapping directly based on the Oak API without
having to go through extra levels of mapping.
Implementation wise, would that en/decoding happen inside oak-jcr or oak-core?
I'd put the JSON-JCR type mapping into a shared helper class in
oak-core since it'll be needed by a lot of things like query and node
type handling inside oak-core. But the API interfaces should IMO be
based on JSON types to support cases where JCR typing isn't needed or
wanted.
having a mapping to JSON is required anyway. the basic question
for me is whether oak-api should use that natively. and in which
cases jcr typing wasn't needed/wanted.
based on my assumption that in our default use-case there is
no remoting between oak-jcr and oak-core i just see the drawback
of converting jcr-Value to json (oak-jcr) and parse it again
to build some sort of oak-Value that have all type information
for validation... instead of having that abstracted in an oak-Value
interface.
since we don't use qualified names, the jcr-value in most
cases was very similar to the oak-value.
having said that: thinking of a ValueFactory implementation
in oak-jcr that creates Value objects that can server both as
jcr-values and oak-values. the internal representation could
still be anything including json-representation... but we
wouldn't be limited to JSON types on the API level.
kind regards
angela
BR,
Jukka Zitting
