Hi,
On Thu, Mar 22, 2012 at 4:53 PM, Stefan Guggisberg
wrote:
> On Thu, Mar 22, 2012 at 4:22 PM, Jukka Zitting
> wrote:
>> 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 e
On Thu, Mar 22, 2012 at 4:22 PM, Jukka Zitting wrote:
> Hi,
>
> On Thu, Mar 22, 2012 at 3:04 PM, Stefan Guggisberg
> wrote:
>> On Wed, Mar 21, 2012 at 8:26 PM, Jukka Zitting
>> wrote:
>>> For oak-core (see OAK-33 [1]) we'd need a bit more detailed definition
>>> of the supported value types. A
On Thu, Mar 22, 2012 at 3:29 PM, Julian Reschke wrote:
> On 2012-03-22 15:04, Stefan Guggisberg wrote:
>>
>> ...
>>
>>> 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, add
On 2012-03-22 15:04, Stefan Guggisberg wrote:
...
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 b
On Wed, Mar 21, 2012 at 8:26 PM, Jukka Zitting wrote:
> Hi,
>
> The MicroKernel interface currently says:
>
>> supported property types: string, number
that's outdated, it now says: string, number, boolean
>
> In addition there's explicit support for binary blobs.
>
> For oak-core (see OAK-33 [