jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: Internal package dependencies in Jackrabbit
Date Thu, 22 Sep 2005 18:25:41 GMT
personally, i think that there is not a lot of value in putting
additional interfaces and "levels of abstraction" into places
just for the sake of "potential extensibility".

with that in mind i think there are a couple of specific places,
where i could see value in additional separation of some
jackrabbit components to actually allow for reuse.

for example: personally, i think that getting the whole
transient space isolated, so it can be re-used for example
to build content repository "clients" more efficiently, would
be great.
i see those content repository "clients" as a part of
jackrabbit.

... and just to mention it: i am not criticising the
current design at all. i think it is much better to build
something tightly coupled and then break it up where it is
necessary than to put in many unused layers of abstraction
and "over complicate" things from the start.

regards,
david

On 9/22/05, Edgar Poce <edgarpoce@gmail.com> wrote:
> On 9/22/05, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> > On 9/22/05, Angela Schreiber <anchela@day.com> wrote:
> > > hi
> > >
> > > Stefan Guggisberg wrote:
> > >
> > > >>Jukka Zitting wrote:
> > > >>>* Move the QName constants from o.a.j.Constants to o.a.j.name.QName
to
> > > >>>  break the o.a.j <-> o.a.j.name dependency cycle.
> > >
> > > eh, that sounds familiar :)
> > >
> > > "[...] for the sake of clarity o.a.j.Constants could be renamed to
> > >   NameConstants [...] and/or moved to the name package."
> > >
> > > > i don't think that you can accomplish
> > > > this by also trying to make it into a generic toolbox/framework for
> > > > building custom jcr implementations. imo we should concentrate on
> > > > making jackrabbit the best opensource jcr repository.
> > >
> > > from my experience with jackrabbit, i would argue, that
> > > there is always room for improvement and that an open
> > > source project should also be the best to be used
> > > from a developer perspective.
> >
> > i absolutely agree.
> >
> > > the blackbox approach
> > > ("don't look at it") does not make too much sense to me in
> > > this case.
> >
> > huh? who was talking about "black box approach"? did i miss
> > something? there are no black boxes in jackrabbit, all the
> > source code is there. all i'm saying is that we should imo
> > concentrate on one goal, i.e. making jackrabbit as robust,
> > fast & scalable as possible. of course this doesn't mean that
> > parts of its code base cannot be reused, that was the motivation
> > behind the former commons subproject. however, imo you can't
> > have both, *the* generic toolbox/framework for building custom jcr
> > implementations *and* the most robust, fastest & scalable
> > opensource jcr implementation, all using the same code base,
> > as this will lead to substantial compromises on one or the other.
> > as i said, we should concentrate on one goal, at least so for the
> > 1.0 release.
> >
>
> I'm not saying that a generic framework should be placed in the core,
> I'm just saying that it would be nice to have reusable components that
> could be used for building such a framework somewhere else.
>
> > btw, i remember that jukka mentioned once that he's working
> > on a framework/toolbox for building custom jcr implementations,
> > but maybe i am mistaken.
> >
> > cheers
> > stefan
> >
> > >
> > > regarding the api: i have the feeling, that there is the need
> > > for a more open design and api in various sections of jackrabbit.
> > > however, this would in my opinion (after working on a jcr
> > > client) lead to more substancial changes (not only extracting
> > > a few interfaces). after all, that's what i consider to be
> > > the future of jackrabbit, in order to make it the best opensource
> > > jcr implementation :)
> > >
> > > regards
> > > angela
> > >
> >
>


--
----------------------------------------------------------------------
http://jcr.day.com JSR-170 in Action!
---------------------------------------< david.nuescheler@day.com >---

This message is a private communication. If you are not the intended
recipient, please do not read, copy, or use it, and do not disclose it
to others. Please notify the sender of the delivery error by replying
to this message, and then delete it from your system. Thank you.

The sender does not assume any liability for timely, trouble free,
complete, virus free, secure, error free or uninterrupted arrival of
this e-mail. For verification please request a hard copy version.


mailto:david.nuescheler@day.com
http://www.day.com

David Nuescheler
Chief Technology Officer
Day Software AG
Barfuesserplatz 6 / Postfach
4001 Basel
Switzerland

T  41 61 226 98 98
F  41 61 226 98 97

Mime
View raw message