JCR JSOP serialize / deserialize

[Tommaso Teofili <to...@gmail.com>]

Hi all,

I'm currently looking / investigating on an interoperable format for
serializing / deserializing JCR nodes and I was wondering how easy it'd be
(or if anything already exists) to use JSOP [1] for that.

The use case would be like follows:
1. get node /a/b/c from JCR as a JSOP
2. send the JSOP object to other machine(s) (e.g. over HTTP)
3. receiver machine writes JSOP into its own repository creating nodes /
properties for /a/b/c accordingly

FileVault works very nicely for that as one can create a VLT package for
certain paths, send the package stream over HTTP and deserialize the stream
using FileVault on the receiving side.

The (eventual) need or maybe advantage of using JSOP could come if the
receiver is not running on a JVM and therefore cannot use FileVault API for
deserialization of the stream, in this case it seems JSOP may be easier to
handle (even if one could rewrite VLT package deserialization in the
receiving platform language).

Just an idea, looking forward to your comments.
Regards,
Tommaso

[1] : http://wiki.apache.org/jackrabbit/Jsop

Re: JCR JSOP serialize / deserialize

[Tobias Bocanegra <tr...@apache.org>]

Hi Tommaso,

I don't think that JSOP is a good format to transport JCR nodes and properties.

flaws:
* lack of extended JCR property type support.
* the property type information is not serialized (2)
* lack of child node ordering support
* lack of namespace transport (1)
* lack of SNNP support (same name nodes and properties)
* possible ambiguity in JSON arrays (2)
* unable to serialize empty typed arrays (2)

1) this could be part of a general header that precedes the actual
transmission of the content.
2) could be solved if type information could be serialized, e.g. in
the property name

also read the first line in [1]:
"Jsop" is the idea of a lightweight HTTP protocol for manipulating
JSON-based object models."

it might make sense to use jsop to implement an rsync-like model,
where you know the receivers state and only send over the patch of
modified content. but this certainly is not useful for vlt.

I once created a JSON based alternative to use in filevault, that
mitigated all the flaws mentioned above, but I never added it to the
trunk. I can try to find it and add it as configurable alternative.
FileVault currently uses a simplified docview serialization, that is
very robust and also designed for human readability.

regards, toby



On Mon, Nov 25, 2013 at 5:06 AM, Tommaso Teofili
<to...@gmail.com> wrote:
> Hi all,
>
> I'm currently looking / investigating on an interoperable format for
> serializing / deserializing JCR nodes and I was wondering how easy it'd be
> (or if anything already exists) to use JSOP [1] for that.
>
> The use case would be like follows:
> 1. get node /a/b/c from JCR as a JSOP
> 2. send the JSOP object to other machine(s) (e.g. over HTTP)
> 3. receiver machine writes JSOP into its own repository creating nodes /
> properties for /a/b/c accordingly
>
> FileVault works very nicely for that as one can create a VLT package for
> certain paths, send the package stream over HTTP and deserialize the stream
> using FileVault on the receiving side.
>
> The (eventual) need or maybe advantage of using JSOP could come if the
> receiver is not running on a JVM and therefore cannot use FileVault API for
> deserialization of the stream, in this case it seems JSOP may be easier to
> handle (even if one could rewrite VLT package deserialization in the
> receiving platform language).
>
> Just an idea, looking forward to your comments.
> Regards,
> Tommaso
>
> [1] : http://wiki.apache.org/jackrabbit/Jsop