Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@xml.apache.org
Date: Wed, 12 Jun 2002 11:42:03 -0700 (PDT)
From: costinm@covalent.net
To: axis-dev@xml.apache.org
Subject: Re: Axis Re-architecture
In-Reply-To: <OFD54A7FCE.B32433EC-ON80256BD6.003D1188@portsmouth.uk.ibm.com>
Message-ID: <Pine.LNX.4.44.0206121120190.1494-100000@costinm.sfo.covalent.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Glyn, 

I have a bit of previous experience with this kind of stuff.
My ( non-commiter ) advice is to wait until v1.0 is out, then 
push for the changes in the main branch, and use the 'revolution'
and proposal/ only if things dead-lock.

Starting fresh may look as a faster solution, but most of the
times a prototype may look clean and simple on paper but 
not in the final product. Making small refactoring steps after 1.0
may be slower, but at least you'll avoid repeating the mistakes
and you'll have measurable and gradual improvements, plus
enough review.

Tomcat3.2 was a pretty major refactoring compared with tomcat3.1,
but it started after 3.1 release. Same for 3.3 - it started
after 3.2 freeze. It is _essential_ to have a stable release
out before refactoring ( if refactoring is what you want ). 

I do agree Axis need some refactoring ( I spent some time debugging
with axis ), and I would love a cleaner core and a more modular
processor. In particular the lower xml layer and abstractions
could be very usefull in many other projects, if decoupled. 
Same for the introspection/marshalling/unmarshalling. 

But I do think it would be very bad if this starts before 
the 1.0 branch is at least frozen and ready for release, and it
would be bad if it is done in a separate tree. Sometimes you need
to make some compromises and maybe 'fight' with other commiters if 
you are in the main branch, but it's worth it. 

Costin


On Wed, 12 Jun 2002, Glyn Normington wrote:

> I plan to start some re-architecture work in a separate xml-axis/proposal
> directory. I have discussed re-architecture with some other committers, but
> few of them are keen to do anything prior to v1.0. I don't want to perturb
> their progress, but I feel some revolutionary change is required (see [1])
> to position Axis well for the future.
> 
> My aim is to build up a clean collection of subsystems along the lines
> described by the architecture guide but with subsystem interfaces actually
> represented properly in the code. I aim to introduce documentation and
> tests as I go in order to maintain intellectual control and enable others
> to join in. If this remains a one person effort, progress will be
> relatively slow, but at least I may be able to demonstrate some facets of a
> clean architecture to guide the future direction.
> 
> As a consequence, my work on JAXM (or more accurately SAAJ) is regretfully
> suspended but may need to be completed by others so that Axis can gain
> JAX-RPC compliance. I don't expect this to significantly impact the overall
> progress of the project as my enthusiasm for that piece of work was rather
> lacking and progress was painfully slow as I hardly ever got round to
> giving it time. There's not a great deal of raw coding to be done, but then
> there is probably a SAAJ TCK to be passed, which involved negotiations to
> get hold of the TCK and a reasonable investment of time to get it running
> and more so to get a pass. I have committed a class diagram change into the
> architecture guide which shows what mapping I planned for the fault-related
> interfaces. This mapping is non completely obvious and certainly doesn't
> match the current code (!). Perhaps a non-committer will step up to doing
> this piece of work as a way of getting involved in Axis (hint, hint!) - I'd
> gladly give advice and encouragement to anyone who is interested. Finally
> regarding JAXM, I would like to apologise to dims publicly as he has been
> the main encouragement for me to do anything on JAXM and I rather feel as
> if I'm letting him down.  I hope he'll understand my passion for pushing on
> towards a clean architecture.
> 
> Glyn
> [1] http://jakarta.apache.org/site/proposal.html#decisions/branches
> 
>