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 jukka.zitting@gmail.com
 designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5107B5E1.8070900@apache.org>
References: 
 <CAOFYJNYAPwy_27Mi27PUofAhrrTE-6ZN1oUKgyLF77rysm7PrA@mail.gmail.com>
 <5107B5E1.8070900@apache.org>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Tue, 29 Jan 2013 14:45:16 +0200
Message-ID: 
 <CAOFYJNZTo+-y7h=vEh5O8cnqYTOQtN2DEk8+dNpkEL=VJaf2xQ@mail.gmail.com>
Subject: Re: MongoMK^2 design proposal
To: Oak devs <oak-dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Jan 29, 2013 at 1:43 PM, Michael D=FCrig <mduerig@apache.org> wrote=
:
> Maybe we can even pick up an earlier idea and use the node type informati=
on
> (i.e. template records here) to optimise how nodes are stored.

That would clearly be useful but I'm a bit hesitant about mixing
higher level concerns like node types with the underlying storage
model, especially since node types are generally mutable (even the
built-in ones changed slightly between JCR 1.0 to 2.0).

The template model as described is a more data-driven approach to the
same problem. It doesn't reach the level of optimization that could be
achieved by making the code understand node types, but on the other
hand it deals very well with unstructured nodes that have no hard
schema but still follow common patterns.

The inspiration for the template idea comes from the way modern
JavaScript runtimes generate and use hidden classes for otherwise
untyped objects.

BR,

Jukka Zitting