Noel,
> > 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. I actually do believe in this as a general statement. A design is not a design until it works. That doesn't mean that the implementation can't have bugs, but it does mean that the basic functionality has to be provided and work as expected. Anything else is virtually an invitation for developers to spend their time doing what most of them enjoy most (designing components) and not doing what most of them enjoy least (testing functionality). BTW, I put myself into this group. A great example of this is AuthService. AuthService was a singleton component that stored authentication credentials in a global fashion. This was a critical bug from day one. Even the simplest negative test case would've exposed the problem. But none was done. Thus I don't consider that design to have any merit - since it never worked, I can't really worry about breaking it. Fixing it in any sense would've required changing the "design", as the auth credentials would've had to have been moved from the global context. I do agree that basic proper function is not a sufficient condition for optimal design, but I will argue that it's a necessary condition. An architecture that precludes proper function is not an optimal design - it's not even a valid one. > 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! Yeah, I've starting coordinating a list by examining the commit messages for the last three months. Lots to do... --Peter -- To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
