A thought on optimisation and project goals

[Alex Blewitt <Al...@ioshq.com>]

There have been several messages in the mailing list talking about 
choices in technology to use within Geronimo, and I feel that some 
choices are being made with the idea of optimisations in mind, rather 
than necessarily other reasons.

I think that in decreasing order of importance when designing and 
building Geronimo, that we should aim for:

1) Functionality -- it should do everything that we expect a J2EE 
environment to do
2) Easy to use and administer
3) Easy to develop and maintain
4) Efficient (memory, computational speed, whatever)

I don't think anyone would argue with (1), but if we want Geronimo to 
be the best (and I'm pretty sure that we are all aiming that way) then 
it probably has to be easy to use and administer over and above 
development ease. But it may be that (2) and (3) could be reordered.

I also think that in order to address (3) there are benefits in linking 
up with as many other projects as possible, rather than develop a Not 
Invented Here syndrome. I am not an Apache member, so I don't know The 
Apache Way (maybe someone can fill it in here), but what it means to me 
is that Apache builds projects that are useful, and that may then be 
integrated into other Apache projects. That certainly seems to be the 
case with the jakarta-commons packages, and indeed there are several 
packages which have been built on top of others (James on top of 
Avalon, Jetspeed on top of Turbine/Velocity, not to mention the uses of 
the commons- packages).

I know that the current focus is on (1) (and probably (2/3) as well) 
for the project, and so a getting-there-fast approach is probably a 
good idea. But let's not write off trying to use other parts (and keep 
them!) from the Apache projects when they're useful; after all, object 
orientation is mainly about reuse.

I personally think that (4) should be the last point on the list, by 
some way. J2EE servers are going to be notoriously powerful beasts, and 
whilst it would be advantageous to run on constrainted hardware, I 
really don't think that's where the target customer base is going to 
be. And as the J2EE spec keeps growing, just to cater for (1) we're 
going to have a lot of code. Optimisations that therefore target (4) at 
the expense of (3) IMHO are going the wrong way; for example, ditching 
the commons packages because Geronimo code (as yet) only uses one 
ReferenceMap.

I also feel that at this stage of the project, trying to squeeze 
performance out of component X isn't the best use of (3). If we have 
two designs, one easier to maintain/extend, and one that is fast, I'd 
prefer the former. Why? Because I don't know that the latter is 
necessarily that much faster, and for that matter, don't know that it 
is in the bottleneck of the code. And until we get a working version 
that we can start running and profiling to find out where the 
bottlenecks are, any optimisation is premature optimisation.

Just my $0.02

Alex.

Re: A thought on optimisation and project goals

["n. alex rupp" <ru...@umn.edu>]

Alex,

I agree with the order of your goals, but there are some hitches in your
reasoning I'm concerned with.

> I also think that in order to address (3) there are benefits in linking
> up with as many other projects as possible, rather than develop a Not
> Invented Here syndrome.

It's very easy to toss around pat rhetorical phrases like "Not Invented Here
Syndrome", but this project is trying to build a certifiable J2EE stack.
The point being that someone must bear the direct responsibility of ensuring
the project's compliance, to the letter of the law (which we're still trying
to get our hands on, if I'm not mistaken) or else we will never accomplish
that goal.  Because we're trying to build and certify an entire stack, we
cannot responsibly demand that other projects hold their efforts directly
accountable to our members.  That runs contrary to our goals and to theirs.
On the other hand, we do have an extremely modular architecture which will
allow small teams to work on the separate subsystems and we have an open
door policy for contributions, so nothing's keeping existing ASF members
from becoming involved--everyone's welcome to help.

> I am not an Apache member, so I don't know The
> Apache Way (maybe someone can fill it in here), but what it means to me
> is that Apache builds projects that are useful, and that may then be
> integrated into other Apache projects.

You're not an Apache committer, but you are a member of the community, which
underlines my following point:  The goal of the ASF is to build a strong and
lasting *community* around technology, without which the technology will
die.  The hope is that strong communities lead to strong and *lasting*
technologies.  Weak communities can build strong technologies--for a time.
But Jason calls that place SourceForget.net for a reason : )

Interoperability of the software is critical, which is why all of the
software is ASF licensed and made available to the rest of the community,
but there is no practical reason why development efforts cannot overlap.
Interoperability isn't mandatory.  That level of inbreeding would be
dangerous to the community.  Competition benefits both teams, and open
disagreement within the ranks is a sign of a healthy and functioning
democratic community.

> I know that the current focus is on (1) (and probably (2/3) as well)
> for the project, and so a getting-there-fast approach is probably a
> good idea. But let's not write off trying to use other parts (and keep
> them!) from the Apache projects when they're useful; after all, object
> orientation is mainly about reuse.

"Getting-there-fast" is probably more important for teams who've never "been
there" before--just to prove to themselves and everyone else they can "get
there" at all.  Nearly everyone on the current committers list has "been
there" before, and I'm certain they're comfortable with the speed at which
they're returning there.  The amount of discussion they contribute to the
list is a good indicator that the development is moving forward at a
satisfactory pace.

> I personally think that (4) should be the last point on the list, by
> some way. J2EE servers are going to be notoriously powerful beasts, and
> whilst it would be advantageous to run on constrainted hardware, I
> really don't think that's where the target customer base is going to
> be.

Not the point. Speed and scaleablity come from clusters.