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 <[email protected]> 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
