Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4F884560.4090507@apache.org>
Date: Fri, 13 Apr 2012 16:25:20 +0100
From: =?ISO-8859-1?Q?Michael_D=FCrig?= <mduerig@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: <oak-dev@jackrabbit.apache.org>
Subject: Re: Encoding of JCR values in json
References: <CBADE595.2A1B5%mueller@adobe.com>
In-Reply-To: <CBADE595.2A1B5%mueller@adobe.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


On 13.4.12 14:40, Thomas Mueller wrote:
> 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.

And this should be done rather sooner than later.

>
>> How could the GC possible know whether a
>> binary is still in use or not?
>> String blobId = 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.

Again, we'd rather be quick here.

Michael

>
> Regards,
> Thomas
>
>