SPI vs. JCR 2.0

[Jukka Zitting]

Hi,

In JCR-1564 I implemented JSR 283 -style namespace handling for both
core and jcr2spi (using common code in jcr-commons). The changes are
compliant with JCR 1.0 and don't require extra API methods, but they
did raise the question of whether we should more generally be
implementing JSR 283 stuff also for the SPI.

WDYT, should we be working on JCR 2.0 compliance for the SPI
components, or should it remain with JCR 1.0 for now?

BR,

Jukka Zitting

[Julian Reschke]

Jukka Zitting wrote:

> Hi,
>
> In JCR-1564 I implemented JSR 283 -style namespace handling for both
> core and jcr2spi (using common code in jcr-commons). The changes are
> compliant with JCR 1.0 and don't require extra API methods, but they
> did raise the question of whether we should more generally be
> implementing JSR 283 stuff also for the SPI.
>
> WDYT, should we be working on JCR 2.0 compliance for the SPI
> components, or should it remain with JCR 1.0 for now?

+1 on introducing JCR 2.0 features the same way it's being done in
jackrabbit-core.

BR, Julian

[Stefan Guggisberg-2]

On Wed, May 14, 2008 at 1:04 PM, Jukka Zitting <jukka.zitting@...> wrote:

> Hi,
>
>  In JCR-1564 I implemented JSR 283 -style namespace handling for both
>  core and jcr2spi (using common code in jcr-commons). The changes are
>  compliant with JCR 1.0 and don't require extra API methods, but they
>  did raise the question of whether we should more generally be
>  implementing JSR 283 stuff also for the SPI.
>
>  WDYT, should we be working on JCR 2.0 compliance for the SPI
>  components, or should it remain with JCR 1.0 for now?

personally i prefer to focus JCR 2.0 compliance efforts on core for the moment
in order to get the JCR 2.0 RI ready as soon as possible.

cheers
stefan

>
>  BR,
>
>  Jukka Zitting
>

[Julian Reschke]

Stefan Guggisberg wrote:

> On Wed, May 14, 2008 at 1:04 PM, Jukka Zitting <jukka.zitting@...> wrote:
>> Hi,
>>
>>  In JCR-1564 I implemented JSR 283 -style namespace handling for both
>>  core and jcr2spi (using common code in jcr-commons). The changes are
>>  compliant with JCR 1.0 and don't require extra API methods, but they
>>  did raise the question of whether we should more generally be
>>  implementing JSR 283 stuff also for the SPI.
>>
>>  WDYT, should we be working on JCR 2.0 compliance for the SPI
>>  components, or should it remain with JCR 1.0 for now?
>
> personally i prefer to focus JCR 2.0 compliance efforts on core for the moment
> in order to get the JCR 2.0 RI ready as soon as possible.

That's perfectly ok :-)

I, on the other hand, would prefer to make SPI changes that we need for
JSR-283 as soon as possible.

Your mileage varies, and there's no problem with that :-)

BR, Julian

[Angela Schreiber]

hi jukka

> WDYT, should we be working on JCR 2.0 compliance for the SPI
> components, or should it remain with JCR 1.0 for now?

basically i think we should have JCR 2.0 compliance for
the SPI as soon as possible. but i prefer having the SPI
only covering JCR 1.0 functionality over ending up with
a SPI that is neither compliant with either version of
the spec due to missing resources.

maybe we can come up with a list of semantic changes
and new features that would allow us to create a very
rough estimation of the efforts needed.

we can then check if this is feasible at all within
the next couple of months and start defining the priority
of each of the  tasks needed for JCR 2.0 compliance or
at least decide on the best way to progress.

kind regards
angela