Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of stefan.guggisberg@gmail.com
 designates 74.125.82.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOFYJNY8f09n9GNEH5YVLA-baVcj-BirG3vBk1oHjUqDFYH1rQ@mail.gmail.com>
References: 
 <CAOFYJNZExHqt=bS21LOraVbYaU+4r_H-=txNGC0b+y_v4EA2VQ@mail.gmail.com>
	<CAFYk8Nk7eTmMdPC0a+=sRFgBxMJOXrCckV9Jy7GL6LSfKOftuA@mail.gmail.com>
	<CAOFYJNY8f09n9GNEH5YVLA-baVcj-BirG3vBk1oHjUqDFYH1rQ@mail.gmail.com>
Date: Thu, 22 Mar 2012 16:53:49 +0100
Message-ID: 
 <CAFYk8N==AQcNxWTdKay2ie=49zU5yDtsvm6F4odvPEj5zxfkOQ@mail.gmail.com>
Subject: Re: Value types supported by the MicroKernel
From: Stefan Guggisberg <stefan.guggisberg@gmail.com>
To: oak-dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 22, 2012 at 4:22 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On Thu, Mar 22, 2012 at 3:04 PM, Stefan Guggisberg
> <stefan.guggisberg@gmail.com> wrote:
>> On Wed, Mar 21, 2012 at 8:26 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
>>> For oak-core (see OAK-33 [1]) we'd need a bit more detailed definition
>>> of the supported value types. A few questions:
>>
>> the microkernel as currently implemented does not interpret property
>> value types, it just stores the value token.
>
> Can we turn that into a harder API contract, i.e. one that should hold
> true for any MK implementation? If not, we need to define the
> boundaries of what oak-core can expect the MK to store reliably. We
> don't need the answers right away, but ultimately this needs to be
> defined for us to properly resolve OAK-33.

ack and agreed. i am fine with specifying a harder api contract something
along the lines of 'values are treated as opaque character sequences'.

>
> A related question, will a value like "\u0058" be considered equal to
> "X" for example when merging concurrent changes? What about [ ] vs. []
> (i.e. extra whitespace within an empty array)?

hmm, now it gets tricky... if the mk treats values as opaque character sequences
it would consider the above examples non-equal. we'll have to see whether
that's an issue. if it turns out to be an issue we'll have to provide
for smarter
merge-logic and perhaps some basic normalization (e.g. removing ws
within arrays).

>
>>> 2) Are null values (the "null" keyword) supported? It would be nice if not.
>>
>> setting a property to null (e.g. ^"foo":null ) removes it (as in JCR).
>>
>> however, adding a node with null valued properties is currently possible.
>> that should probably be fixed.
>
> OK, sounds good. So oak-core can treat a case like {"foo":null} being
> returned from MicroKernel.getNodes() as an unexpected error, probably
> caused by an administrator directly accessing the MicroKernel.
>
>>> 3) Are arrays (i.e. "[" ... "]") supported? If yes, are there
>>> constraints on element types? It would be nice if arrays indeed were
>>> supported. With the restriction that all elements are scalar values of
>>> the same type.
>>
>> it does support arrays but doesn't enforce restrictions.
>>
>> the microkernel should IMO just support the basic json model.
>> restrictions should be handled on a higher level.
>
> OK, cool.
>
>>> 4) Are there limits on number values? Most notably, can a number
>>> that's larger than Long.MAX_VALUE be stored reliably (as a number)?
>>> Larger than Double.MAX_VALUE? What about things like Double.NaN? Or
>>> weirder, the other 2^51 NaN values allowed by IEEE754?
>>
>> whatever you pass in the commit is stored and returned as-is.
>> as already mentioned, the value is (currently) not interpreted.
>
> OK. Can we get rid of the "(currently)" qualifier? Also, the "not
> interpreted" part needs to be qualified in terms of things like
> conflict merging. I'd be fine with "store and used as an opaque,
> unparsed character sequence".

i agree with that wording.

cheers
stefan

>
> Basically this means that in oak-core or -jcr we need to either a) not
> support all possible Java double values or b) use some custom string
> encoding for such values. I suppose a) is the better alternative, but
> we need to check whether that will cause problems down the line.
>
>>> 6) Presumably strings are in Unicode. Are characters beyond the BMP
>>> supported? Is it possible for a string value to contain a Unicode
>>> non-character, for example U+FFFF?
>>
>> erm, haven't thought about that. do you think that there could be a problem?
>
> Like with the Double.NaN case, unless the underlying MicroKernel
> supports the full range of characters, we need to consider adding some
> extra level of encoding (possibly simply the \uNNNN escapes) on the
> oak-core or -jcr level. But it sounds like this won't be needed.
>
> BR,
>
> Jukka Zitting