jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: Encoding of JCR values in json
Date Fri, 13 Apr 2012 12:35:00 GMT
On 2012-04-13 14:24, Michael Dürig wrote:
>
>
> On 13.4.12 12:43, Jukka Zitting wrote:
>
>>>> * The explicit encoding of numeric constants from JCR seems a bit
>>>> troublesome and makes potential extensions more cumbersome.
>>>
>>> What extensions come to mind?
>>
>> For example some applications might well want to be able to store
>> things like coordinates (think of geospatial search) as individual
>> scalars instead of collections of properties. Or there might be a
>> desire to have a custom property type for say email addresses or phone
>> numbers just like we have one for URLs in JCR 2.0. Or there could be a
>> need for storing date and time values separately instead of the
>> current timestamp values used in JCR. We don't have a current need for
>> things like these, but a future JCR version or another standard or use
>> case we want to support might well change that. Having an extensible
>> typing mechanism makes implementing such things easy.
>
> Makes sense. If we get rid of the explicit encoding using the numerical
> constants from PropertyType and use a more open approach we should be
> fine extension wise however.
>
> [...]
>
>>> The trouble with that is, that type info and value are spread across
>>> different properties. Setting a JCR property requires two JSON diff
>>> operations here.
>>
>> I don't think that would be too troublesome since the standard string
>> and number formats cover the majority of properties.
>>
>>> Worse for JCR observation: the corresponding set property entries
>>> might be spread across the journal.
>>
>> I'm not sure I follow. You mean a case where the value is set in one
>> revision and the type in another? That should be interpreted as two
>> setProperty() operations, each with different value types.
>
> What I meant is: creating the JCR observation events from the
> Microkernel journal might be troublesome since the two setProperty
> operations (one for the value and the other for the type) are not
> guaranteed to be anywhere close to each other in the journal.
>
>>
>>> So there are three different approaches now: 1) encoding the type
>>> into the
>>> value, 2) encoding it into a separate property, or 3) encoding it
>>> into the
>>> name of the property.
>>
>> Microsoft chose a fairly smart variant of 1 for ASP.NET, see
>> http://weblogs.asp.net/bleroy/archive/2008/01/18/dates-and-json.aspx
>>
>> For us that would mean something like this:
>>
>> "example":{
>> "long":123,
>> "another long":"\/Long(124)",
>> "double":"\/Double(123.4)",
>> "string":"foo",
>> "another string":"/string"
>> }
>>
>> The only trouble is that for this to work we need to require the
>> MicroKernel to keep track of the exact character sequences instead of
>> just the logical, unescaped strings. Currently this indeed is the
>> case.
>
> Tom brought that up earlier already. I'm a bit sceptic about using a
> loop hole in the spec since clients using standard JSON parsers might
> not be able to distinguish between the long value
>
> "a long":"\/Long(124)"
>
> and the string value
>
> "a string":"/Long(124)"
>
> because in both cases they only see the un-escaped value which is the same.

Absolutely.

I wouldn't call it a "loophole". The trick just relies on an 
implementation detail of a specific JSON implementation. (Which reminds 
me of member ordering :-).

> ...

Best regards, Julian

Mime
View raw message