On 2015-01-12 09:12, Thomas Mueller wrote:> Hi,
>
>>
>> 1) I feel uncomfortable about using something for JSON that has been
>> written for a different purpose (JSOP), allowing certain extensions I
>> definitively don't want to use.
>
> You'll need "non-standard" JSON if you want to use concatenation as
> follows:
>
> data = "r1: {a: 1}"
>
> update ... set data = data || ", r2: {a: 2}"
>
> data = "r1: {a: 1}, r2: {a: 2}"
>
> Standard JSON would require an array, so you would need "[" at the
> beginning and "]" at the end. But having "]" at the end would role out
> using concatenation.
That is true. The RDBDocumentStore currently uses a comma-separated list
on JSON thingies. It can be parsed as array contents (where the naive
approach is to simply put it inside "[...]" before invoking the parser).
> Also, standard JSON would need double quotes around all identifiers,
which
> uses more space.
Yes. But I really really don't want to use a custom format inside the
persistence, unless it gives me huge performance gains (such as
switching to a binary format).
>> 2) For parsing, it seems that the only thing I *could* use is the
>> JsopTokenizer, which a) does not seem to do anything than strings (this
>> is probably by design, as it is just a tokenizer), and is also very weak
>> on documentation (what is the parameter for "read(int)"?).
>
> This is documented. From the Javadocs of JsopTokenier.read:
>
> /**
> * Read a token which must match a given token type.
> *
> * @param type the token type
> * @return the token (a null object when reading a null value)
> * @throws IllegalStateException if the token type doesn't match
> */
> @Override
> public String read(int type) {
>
>
> JsopReader.read:
>
>
> /**
> * Read a token which must match a given token type.
> *
> * @param type the token type
> * @return the token (null when reading a null value)
> * @throws IllegalStateException if the token type doesn't match
> */
> String read(int type);
I see it's invoked with type == '{' -- so what exactly is a type?
>> 3) JsopBuilder escapes many characters that do not need to be escaped.
>
> Yes, there is a TODO in the escape method. This can be changed if needed.
OK, I can give it a try.
>> If this is supposed to provide JSON support for Oak, it definitively
>> needs work...
>
> I understand it is not 100% optimal for your use case. But then, we can
> more easily change / extend it than a standard JSON library :-)
Ok, so do we have a consensus that we can tune/extend it for the purpose
of offering compliant JSON support as well?
Best regards, Julian
