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
Hi Roy,
Thanks for helping me crystallize my thoughts and
trying to sharpen my statements ;)
That is why each of the core developers has veto power over the code.
If we want to ensure that every line is adequately reviewed, then ask
for the core code to be governed by the RTC (review-then-commi
On Sep 6, 2006, at 4:14 AM, David Nuescheler wrote:
Personally, I believe that for example a "restore" facility has to be
buried deep down in the core and therefore the code has to comply
with the high quality requirements that we have for code in the core
and for the seasoned "Jackrabbit experi
Hi,
On 9/6/06, David Nuescheler <[EMAIL PROTECTED]> wrote:
Got it. Generally, I am more of a "given the right eyeballs, all bugs
are shallow" type of person to begin with.
Perhaps we can find common ground at "enough right eyeballs". ;-)
If I currently take look at the "shallowness" of actua
Hi Nico,
Thanks for your mail.
I will work on the documentation directly on the wiki (when I can start this
task). I will ask a lot of questions *though*.
Looking forward to it ;)
One precision on the backup tool: it is working (and I am polishing the code
that needs to fit in Core). And wit
Hi David,
Good points.
I will work on the documentation directly on the wiki (when I can start this
task). I will ask a lot of questions *though*.
One precision on the backup tool: it is working (and I am polishing the code
that needs to fit in Core). And with my "new" JR understanding, I plan
Hi Jukka,
Thanks for your thoughtful comments.
I'm most concerned about the overhead for people going in trying to
trace why Jackrabbit is behaving the way it does in some specific
issue. This is often the first step of becoming a contributor, and in
my opinion it's currently quite a high step
Hi Nico,
thanks for your explanations.
My point was unclear: I meant JR core would have more functionnality (and
some new ones are still needed) with a little bit of documentation of this
part. I would gladly work on this part with your help since I will need to
understand some parts better tha
Hi Stefan,
Cleaner code is a consequence of the current quality control process through
patches review; not something my point would lead to.
My point was unclear: I meant JR core would have more functionnality (and
some new ones are still needed) with a little bit of documentation of this
part.
Hi,
[Hmm, too quick with the send button... more below.]
On 9/6/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
On 9/6/06, David Nuescheler <[EMAIL PROTECTED]> wrote:
> While I agree that we need to have a modular design where people can
> plug-in their extensions at certain defined interfaces and
On 9/6/06, Nicolas <[EMAIL PROTECTED]> wrote:
On 9/6/06, David Nuescheler <[EMAIL PROTECTED]> wrote:
> While I agree that we need to have a modular design where people can
> plug-in their extensions at certain defined interfaces and extension
> points,
> I would discourage the idea that every us
Hi,
On 9/6/06, David Nuescheler <[EMAIL PROTECTED]> wrote:
Personally, I think we have to separate the concerns though, I think
Jukka's initial post was going into the direction of making the internals
of the core more accessible to more developers.
Correct. In any case, Dave's points are a va
On 9/6/06, David Nuescheler <[EMAIL PROTECTED]> wrote:
While I agree that we need to have a modular design where people can
plug-in their extensions at certain defined interfaces and extension
points,
I would discourage the idea that every user needs to be able to submit
patches to the core.
In
Hi All,
Dave, thanks a lot for your input.
. Screenshots or easily downloadable sample app which
actually does something with custom node types. the base war
download is good, but how far could you go with it. Most open
source applications have a contacts application or a phone book,
or somethi
I will put in my 2c since I did not see many replies to this post and I think
addressing this question is very important for any open source project. i have
not had much time to play with JR due to other work, so some of this might
already be there.
. Screenshots or easily downloadable sample a
Hi,
I have got familiar with JR codebase in the last few months and follow is
based on my experience in the backup tool.
The community is really helpful when you need some help but in order to
understand the basic concept you need to dig into the code and into the JCR
spec.
A general documentati
Hi,
Based on private discussions I'd like to raise the issue of the
accessibility of the Jackrabbit core codebase. We have a small number
of people who are intimately familiar with the core codebase (see the
numbers below), but others find the core hard to navigate and that
this drives up the bar
23 matches
Mail list logo