Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of mueller@adobe.com designates
 64.18.1.25 as permitted sender)
From: Thomas Mueller <mueller@adobe.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Date: Fri, 13 Apr 2012 14:40:50 +0100
Subject: Re: Encoding of JCR values in json
Thread-Topic: Encoding of JCR values in json
Thread-Index: Ac0Zewoxgq+b2DrHRO6t0mBTejiolg==
Message-ID: <CBADE595.2A1B5%mueller@adobe.com>
In-Reply-To: <4F87F795.8050507@apache.org>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

>>An alternative might be: numbers with an "e" are double ("10e0"), numbers
>> with a dot are decimal ("10.0"), all other numbers are long ("10"). But
>> that would require the MicroKernel stores the *exact* JSON
>>representation.
>> I don't think that's a good idea either.
>
>The underlying storage mechanism must not be of concern to the user of
>the Microkernel API. The Microkernel API uses JSON to transport values.
>So the Microkernel implementation is in charge of serializing these into
>a format suitable for the underlying storage mechanism. Even if I put a
>number with 10 Million digits into a JSON property.

I think we should not rely on the MicroKernel implementation to support
unlimited precision numbers. For example MongoDB only supports IEEE 754
floating point numbers, as defined by the BSON spec:
http://en.wikipedia.org/wiki/BSON - so we can't store BigDecimal as a JSON
number, because we would risk losing precision.

Also, I would not rely on the MicroKernel implementation to preserve the
exact JSON representation. If we store the number as 100.00, we should not
rely on getting 100.00 back. We might as well get 100.0 or 100 back.

We should document this in the MicroKernel specification. The JSON
specification itself doesn't define such details.

>How could the GC possible know whether a
>binary is still in use or not?
>String blobId =3D mk.write(inStream);
>
>and write the returned blobId on a piece of paper. According to the
>current Microkernel contract I could come back after a couple of years
>and would still be able to retrieve that blob.

Yes, we need to narrow the contract.

Regards,
Thomas