Hi,
However, I'm a bit concerned about the revolutionary approach of the
SPI effort. Rather than refactoring the Jackrabbit core to better
separate the session-local parts, the SPI comes up with a brand new
interface contract. This is probably the best thing to do given the
SPI goals, but it doe
Hi,
On 9/7/06, David Nuescheler <[EMAIL PROTECTED]> wrote:
In my mind the introduction of the SPI would lead to a clean
split of the Jackrabbit core architecture that allows for
much better re-use and better transparency. Essentially
the "core" could be reduced to the "server" which should
sigin
Hi Thomas,
Thanks for your thoughtful comment.
I don't understand why it needs to be stateless (about my understanding of
stateless, see http://en.wikipedia.org/wiki/Stateless_server). As far as I
see stateless means it's slower, and I really don't like slow ;-) Even HTTP
is becoming more and m
-level
interface and the JCR Driver "translates" this into a
standards-compliant API.
Miro
-Original Message-
From: David Nuescheler [mailto:[EMAIL PROTECTED]
Sent: 07 September 2006 10:00
To: dev@jackrabbit.apache.org
Subject: Nuclear Fission, Splitting the core: The SPI Effect
Hi,
I think it's a good thing to do. Some random ideas:
I don't understand why it needs to be stateless (about my understanding of
stateless, see http://en.wikipedia.org/wiki/Stateless_server). As far as I
see stateless means it's slower, and I really don't like slow ;-) Even HTTP
is becoming mo
oops...
[1] http://jackrabbit.apache.org/images/arch/jackrabbit-ism.jpg
should have been:
[1] http://jackrabbit.apache.org/images/arch/jackrabbit-ism_small.jpg
Hi All,
I would like to use Jukka's initiative as a starting point to discuss
a couple of high level architecture topics around the SPI initiative
and its potential effect on the overall Jackrabbit architecture.
Please consider all of the following comments as my
personal views which I would lik
