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
