Steve Brewin wrote:
Bernd Fondermann wrote on: 29 January 2008 08:46:
Hi,
Since we have so many road blocks on our track ahead... why don't we
simply start a rewrite?
Before we all throw in our -1's, let's just think about it
for a minute...
Truely, coding the current stuff is _no_fun_. How do we expect this
project to gain track if nobody is volunteering for coping
with this pain?
We have _not_enough_long_term_committers able and willing to
deal with
legacy stuff. The world has _moved_on_. Can't we build
something which
is comprehensible? The whole backend repository architecture and how
things are propagated, well, I don't get it and I think it'd
better be
replaced. And I don't even figure out how to replace stuff there.
Whenever I look at this stuff I start with... putting it away.
Many important features from the last couple of months could
(IMHO) not
be integrated seamlessly. Because current JAMES is not easily
extensible
and generally does not welcome changes. We have some cool ideas like
async handlers etc. And people invest their time trying to
fit it into
the current architecture, where this energy is better spent
writing even
more cool features and making the server unbreakable. We have tight
integration with JavaMail. This alone has probably cost us so
much time.
(Re-reading the last paragraph, it seems a little bit like a
rant to me,
don't you think? But I feel better now. Anyway...)
Not a rant, simply a venting of the frustrations all developers feel at
times. Sure, with unlimited resources we could craft a better solution for
todays challenges starting with a clean slate, decanting all of the
knowledge captured in the current codebase in a cleaner, better way.
But consider the lesson of the old joke of the lost traveller who asks a
passing stranger how to get to his intended destination and is told, "Well,
If I were you I wouldn't start from here". Sometimes we have no realistic
alternative but to start from where we are.
:-)
Yes, we have a responsability, to make things easy for our users,
support migrations, be defensive with changing APIs and so
on. But how
does that help if we are unable to push this dinosaur forward? Or
foremost responsability is to make this a fun place to be,
make people
contribute and hand out fine releases. I think we have come to a
situation where we might be better off with creating
something new from
scratch.
The efforts of you, Robert and others have shown that we can make progress
through evolution without revolution. I think the trick is to find a way of
folding these efforts back into a releasable codebase is the way forward.
This is being discussed elsewhere on this list, "[PLANNING] Road map - lets
find some consensus on .... release contents ...", and is preferable, not
least because it is realistically doable.
What things do you feel are truly road blocked by core architecural issues
in the codebase as opposed to a frustrating lack of developer activity? Such
core architecural issues could be added to the roadmap as must do's to
resolve so that they are generally understood by all. Maybe then, some would
find "this a fun place to be" in resolving them.
Thanks Steve, for your great reply. :-)
Yes, revolutionary changes are problematic, no changes either. Sometimes
it needs a mini-revolution. This takes time and preparation and the lack
of this maybe is more frustrating than all code-related issues. Sooner
or later I hopefully find the time to paraphrase in more technical words
what I consider architectural issues. ;-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
