jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Encoding of JCR values in json
Date Fri, 13 Apr 2012 07:12:15 GMT
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

Mime
View raw message