> Except you keep blocking submission with -1 votes.
Did he? Or were they simply implied? It has been so long, I honestly don't
recall. And at this point, since we are moving forward, I DO NOT CARE. I
do, however, believe that should all relax and move forward with as much
harmony as we can muster.
As for "design changes", hopefully we can all agree with something I posted
a few minutes ago, to wit:
- As a general rule, micro-change is less stressful than macro.
But not necessarily more correct.
- Sometimes a change of design is good, or even necessary.
Those things should be discussed.
- Not every change that moves code is a design change,
and not every class is part of the design.
Now, in the context of this thread, as opposed to the other one where I
really want to keep the discussion on the Apache philosophy and not our
current issues, I will say that I consider BaseConnectionHandler to fall
into that last category. It is a class that clearly was part of the
implementation, but not a design element.
> Of the changes discussed to date, the only one that is arguably a
> "design change" is removing the dependency on the scheduler.
Actually, I would disagree with that argument. The Watchdog fills exactly
the same role in the design that the Scheduler was used to fill. There is
no design change. If anything, tying handlers more closely to their server,
rather than having a handler as an pseudo-independent construct, could be
viewed as a design change, although a minor design change with significant
positive implementation benefits. We still have the same design elements,
all filling the same roles. All that has changed is a bit of linkage.
> In short, if something doesn't work it doesn't
> constitute a design.
I don't agree with that as a general statement, and I don't believe that you
do, either. Bugs do not invalidate design. Architecture, design and
implementation each has a role, and a defect in one does NOT imply a defect
in another. Bugs exist and can be fixed. For that matter, proper operation
does not imply that the design or architecture is correct, but as Thomas
Kuhn would likely argue, we often require failure before we are motivated to
undertake structural change.
Again, as for the rest, I think that we're moving forward, should leave it
at that, and do what we can to keep James established as an attractive
community for developers interested in a high quality, flexible, mail
server.
I took a look at the change log that Serge put out for each prior release;
boy, do we have a lot of work to do pulling that together for 2.1!
--- Noel
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
