Issue Links

Activity

We also should make a conscious decision about whether we really do JSON, or just use JSON-like syntax. In the former case, we need to eliminate all stuff that is not really guaranteed by JSON (as defined in RFC 4627), such as the ordering of members being considered relevant.

Julian Reschke
added a comment - 16/Mar/12 09:27 +1
We also should make a conscious decision about whether we really do JSON, or just use JSON-like syntax. In the former case, we need to eliminate all stuff that is not really guaranteed by JSON (as defined in RFC 4627), such as the ordering of members being considered relevant.

two implementations (JsopStream and JsopBuilder),
we might not need JsopBuilder

org.apache.jackrabbit.mk.json.JsopReader

a low-level tokenizer with a stax-type interface

two implementations (JsopTokenizer and JsopStream),
where JsopStream is very good for pipelining as it
avoids to create/parse strings

Plus we have org.apache.jackrabbit.oak.jcr.json.*, but unfortunately
I don't have an overview about that currently. Some classes are named
Jsop* and some Json* but it seems both can actually parse / generate jsop?
Not sure if some of those classes only support json?

Thomas Mueller
added a comment - 16/Mar/12 09:58 +1
There is json, and jsop (json-diff), which is a superset of json.
We anyway need jsop, so we might not need the same tools in the json variant.
As for jsop, what I wrote is:
org.apache.jackrabbit.mk.json.JsopWriter
the interface is basically JSONWriter
http://www.json.org/javadoc/org/json/JSONWriter.html
two implementations (JsopStream and JsopBuilder),
we might not need JsopBuilder
org.apache.jackrabbit.mk.json.JsopReader
a low-level tokenizer with a stax-type interface
two implementations (JsopTokenizer and JsopStream),
where JsopStream is very good for pipelining as it
avoids to create/parse strings
Plus we have org.apache.jackrabbit.oak.jcr.json.*, but unfortunately
I don't have an overview about that currently. Some classes are named
Jsop* and some Json* but it seems both can actually parse / generate jsop?
Not sure if some of those classes only support json?

> we need to eliminate all stuff that is not really guaranteed by JSON (as defined in RFC 4627), such as the ordering of members being considered relevant.

that's not the case anymore.

"a node consists of an unordered set of name -> item mappings.
each property and child node is uniquely named and a single name can only refer to a property or a child node, not both at the same time." [1]

Stefan Guggisberg
added a comment - 16/Mar/12 10:14 > we need to eliminate all stuff that is not really guaranteed by JSON (as defined in RFC 4627), such as the ordering of members being considered relevant.
that's not the case anymore.
"a node consists of an unordered set of name -> item mappings.
each property and child node is uniquely named and a single name can only refer to a property or a child node, not both at the same time." [1]
[1] http://wiki.apache.org/jackrabbit/RepositoryMicroKernel

Thomas Mueller
added a comment - 16/Mar/12 10:30 As a first step, I guess it would make sense to combine the low-level generators/tokenizer.
The next step is unify the higher level stuff (working from bottom to top).
I would volunteer to try to combine the low-level tokenizing / building of jsop.
I would work together with Michi to do that.

Michael Dürig
added a comment - 16/Mar/12 10:41 The parsers in org.apache.jackrabbit.oak.jcr.json [1] grew out of of the need for parsers which are composable, extensible flexible and offer sufficient abstractions.
[1] https://github.com/mduerig/json-jerk/blob/master/README.md

Yes, the parsers at org.apache.jackrabbit.oak.jcr.json offer a higher level abstraction than what is in org.apache.jackrabbit.mk.json. Within MicroKernel implementations, possibly the low-level abstractions are sufficient (a StAX parser for example), but within other components the high-level abstractions (DOM based / event based) make sense. I believe the high-level abstractions could be built on top of the low-level abstractions.

According to my tests, avoiding to generate String is a lot faster (as it completely avoids escaping / de-escaping and copying), and requires much less memory. This is the reason for JsopStream.

I wonder if we should try to keep all json / jsop related stuff in one project, and if yes in which one.

Thomas Mueller
added a comment - 16/Mar/12 11:06 Yes, the parsers at org.apache.jackrabbit.oak.jcr.json offer a higher level abstraction than what is in org.apache.jackrabbit.mk.json. Within MicroKernel implementations, possibly the low-level abstractions are sufficient (a StAX parser for example), but within other components the high-level abstractions (DOM based / event based) make sense. I believe the high-level abstractions could be built on top of the low-level abstractions.
According to my tests, avoiding to generate String is a lot faster (as it completely avoids escaping / de-escaping and copying), and requires much less memory. This is the reason for JsopStream.
I wonder if we should try to keep all json / jsop related stuff in one project, and if yes in which one.