----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, June 13, 2002 12:26 PM Subject: Re: Axis Re-architecture
> On Thu, 13 Jun 2002, Glyn Normington wrote: > > > Costin: I'm aiming more at a radical re-architecting rather than a > > re-factoring. My goal is not primarily to preserve the current function as > > some of this is there by accident of the current structure. > > I was afraid of that... > > If I remember corectly, axis is a 're-architecting' of xml-soap. What > makes you think the next one will be the right one ? And when does it > stop, I assume someone else will start re-architecting your version > when it's almost ready ( by that time is very likely it'll be > close to a real product, i.e. with all the compromises and complexities). One of my favourite books on system design is "How buildings learn, by Stuart Brandt". Its core premise is that old buildings either survive because their purpose is frozen (churches, cathedrals), or because they were reworked during their life. Unless you can guarantee that purpose is frozen forever, flexible is best. And even the fixed function cathedrals are really hacks with things like flying buttresses in to hold up the sides. > I totally agree axis has become too complex, it's hard for new people > to contribute, etc. There are some amazing ideas in it, and a lot > of the normal complexity that you find in any project that matures > and has more than one contributor. > > But IMHO the only way to fix this is the hard way - starting with > the existing system and cutting the crap, create a set of simpler > interfaces and remove interdependencies, etc. > > At least that's my experience with several 're-architecture' attemtps, > including Axis itself. It all looks wonderfull on paper and the first > draft, and it repeats most of the errors and gets all the complexity > of the original ( because of natural evolution ). yup. > > The only way to get to a simple and modular system is to start with > a real system and refactor it continuously, based on the features and > code that gets added. Maybe a good tactic is post1.0 to pick a really unwiedly bit of the system and redesign it. One can prepare for this in the pre-1.0 timeframe by writing all the unit tests that refactoring needs, these will benefit both releases -steve
