On Thu, Mar 22, 2012 at 4:22 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Thu, Mar 22, 2012 at 3:04 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
On Wed, Mar 21, 2012 at 8:26 PM, Jukka Zitting jukka.zitt...@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+?
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 \u escapes) on the
oak-core or -jcr level. But it sounds like this won't be needed.
BR,
Jukka Zitting
