Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of fmeschbe@adobe.com designates
 64.18.1.25 as permitted sender)
From: Felix Meschberger <fmeschbe@adobe.com>
To: "oak-dev@jackrabbit.apache.org" <oak-dev@jackrabbit.apache.org>
Date: Fri, 9 Mar 2012 16:40:07 +0000
Subject: Re: On setting component boundaries in Oak
Thread-Topic: On setting component boundaries in Oak
Thread-Index: Acz+E0dl0QB1lPuqSr+IjMYz4IrQeg==
Message-ID: <C7D9C3A9-0353-4614-87FE-767EACF751AF@adobe.com>
References: 
 <CAOFYJNZhxUD5RSVkqO+sxeSQmKQ6qmX-YS0jBLbTs=05J0CNqA@mail.gmail.com>
In-Reply-To: 
 <CAOFYJNZhxUD5RSVkqO+sxeSQmKQ6qmX-YS0jBLbTs=05J0CNqA@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi,

Replying over all to this thread..

My take is, that we try to create such separate projects right from the sta=
rt. Yes, I am already thinking in Bundles. But having separate projects als=
o makes it easier to really keep separate things separate. I mean, it is im=
possible to polute some code with a dependency on another package which exp=
oses implementation details (see for example the NodeId parameters of Jackr=
abbit 2 PersistenceManager interface).

Yes it makes development a bit harder at the beginning -- but maintence wil=
l be a lot easier.

Also, if the package space is properly separated between the modules, it is=
 much easier to find the correct location of code. The problem with Jackrab=
bit 2 is, that this package space is not properly separated and that some p=
ackage expected in the one module is actually in a different one (for examp=
le the jcr-server module hosting "webdav" packages which would be expected =
in the webdav module).

And yes, I would create a MK API module separate from the Oak default MK im=
plementation. As I said elsewhere this helps other implementations as well =
as providing testcases to validate MK implementations.

And yes, I would create a proper/separate Oak SPI, which is optimized for c=
ommunication between the transient space implementation part and the actual=
 Oak implementation part. Again having a separate Oak SPI module would help=
 separating API from leaking implementation detail and help build validatio=
n tests.

Regards
Felix=20

Am 09.03.2012 um 03:58 schrieb Jukka Zitting:

> Hi,
>=20
> Following up on OAK-5, where the question came up on whether we should
> put the JCR binding for Oak to a separate oak-jcr component or just
> under an .oak.jcr package in oak-core. There are good arguments for
> both approaches, and the balance of the different solutions also
> depends on the state of the overall architecture.
>=20
> Before making the decision on this, here's a few questions to consider:
>=20
> 1) What's the main API through which functionality in oak-core (and
> the potential low-level extensions it interacts with) shall be
> accessed? Shall things like node type handling, versioning, locking
> and query support be included in that API? AFAIUI the MicroKernel
> interface is intended more as an internal extension point and remoting
> API instead of something that a client (including one like a specific
> protocol binding) would directly interact with, so it probably
> shouldn't be the API through which other components access
> functionality in oak-core.
>=20
> 2) What kind of clients will interact directly with Oak through JCR
> vs. some lover level API (call it Oak SPI for now)? For example, do we
> want to build a WebDAV or JSON/JSOP protocol binding based directly on
> the Oak SPI or should they work on top of the JCR binding like they
> currently do in Jackrabbit 2.x? Using an appropriate lower level API
> might make it easier or even possible to implement things like ETag
> support for WebDAV.
>=20
> 3) Given that such an internal Oak SPI is needed above the MK level,
> are we confident enough that we know where that boundary between
> oak-core and the proposed oak-jcr components should be set and what
> the boundary should look like? Making a premature decision on that
> could easily become a self-fulfilling prophesy that binds us to a
> specific architectural layout. For example the current Jackrabbit SPI
> has some inherent design limitations that are very hard to fix anymore
> given that plenty of client code is already using it.
>=20
> BR,
>=20
> Jukka Zitting