You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Bernd Fondermann <bf...@brainlounge.de> on 2008/02/04 22:19:02 UTC

Re: [DISCUSS] road blocked... please pave a new way

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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org