Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Message-ID: <20040726013914.38488.qmail@web40608.mail.yahoo.com>
Date: Sun, 25 Jul 2004 18:39:14 -0700 (PDT)
From: Samisa Abeysinghe <samisa_abeysinghe@yahoo.com>
Subject: RE: Improving / re-factoring Axis C++
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
In-Reply-To: <000001c470b4$34ba1110$0a65a8c0@SusanthaNB>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Susantha Kumara <susantha@opensource.lk> wrote:
> > -----Original Message-----
> > From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> > Sent: Friday, July 23, 2004 1:20 PM
> > To: Apache AXIS C User List; 'Apache AXIS C Developers List'
> > Cc: 'Apache AXIS C User List'
> > Subject: Re: Improving / re-factoring Axis C++
> > 
> > To me this sounds like lots of engineering/reengineering work.
> > I would like to suggest a divide and conqure approach, where one
> module is
> > addressed at a time.
> 
> Yes this is lots of re-engineering work. Its true that we can do this by
> module by module. But It would take lot of developers time for testing.
> Also this approach would make the developers dependent of each other
> (one may be waiting till the other finishes one module etc). So onece we
> figure out what changes we are going to do we can go ahead and do it.
> After we feel that we have finished with refactoring etc we can
> integrate and test it.
> 

Well, refactoring is about testing. Lots of systematic testing to keep the fetures already there
in place. Changes are structural. The challenge is to keep functional as it is.
That was the rationale for a module based approach, for which more resources are required.
On the other hand, why refactoring is required on the current code base is because one developer
was working on one module; it is better to benifit from the pronciple 'two heads better than one'.

> What I would suggest is that we do these re-factoring in few weeks (say
> 3-4 weeks) and then start integration and testing etc to make it stable.
>  

If what you really want is refactoring this will *not* work. It starts with testing and testing
should continue throughout - this makes sure that any side effects we introduce while we go on
refactoring are handled on the spot; You cannot refactor and then test; that simply does not work.

> > 
> > As I have mentioned earlier, I too have some comments on
> > serializer/deserializer and transport
> > coupling, which I came to notice during the implementation of LibWWW
> > transport.
> > 
> > I also think that it will be a good idea to consider mails in the past
> on
> > the same subject over
> > mailing list related to design. I had couple of them sent (e.g. on the
> 
> I have considered most of the feedbacks I got in the mailing list.
> Please feel free to point out any miss outs. Also I would like if you
> add to the following list any other re-factoring suggestions (with
> detailed explanations) in any code segment (file, API, modules etc).
> 
> > stub level copy
> > constructing that I had to do because of the state related problems in
> the
> > engine; may be not
> > engine problems but still worth considering). Personally I believe
> state
> > management is important.
> > (This feeling gets stronger, as I am looking into thread safety issues
> of
> > LibWWW these days.)
> 
> Will focus on keep Alive and chunking too.
> 
> > 
> > Another suggestion would be to sync these new items with WS-I and
> other
> > similar kinds of
> > compliances. Now we know the problems, we would be in a better
> position to
> > more easily achieve
> > compliance in the future improvements.
> 
> If you could prepare is list on non-compliant areas that would be a
> great job.

I wish I had time to do this ;-)

>  
> > 
> > I am not sure how much this would apply to an open source project, but
> I
> > would like to reverse
> > engineer the source and build the current desing model, to more
> > objectively asses the current
> > desing, before jumping into refactoring.
> 
> This too is very good because it would also help the recent developers
> to easily understand and figure out any problem / areas to improve etc.
> 

Well I did not mean for *recent* developers. What I meant was that in therms of OO norms and
refactoring principle, in order to know where you are starting from and define where you want to
end up, you got to build the current design model, in detail. 

> Thanks,
> 
> Susantha.
> 
> > 
> > Samisa...
> > 
> > --- Susantha Kumara <susantha@opensource.lk> wrote:
> > > Hi all,
> > >
> > > After the recent discussions with Aleksander Slominski we realized
> that
> > > we had made following mistakes when we were designing Axis C++
> (Actually
> > > iterative designs).
> > >
> > > 1. Supporting C on top of C++
> > > 2. Not using Exceptions for error handling. This made error handling
> > > incomplete and complicated.
> > > 3. Excessive use of STL.
> > >
> > > So following are the improving/refactoring considerations of Axis
> C++. I
> > > suggest we create a branch and continue this
> refactoring/improvements
> > > etc so that the CVS HEAD is not affected. In the future when this
> branch
> > > is very stable we may consider it to be merged with the HEAD
> (probably
> > > for Axis C++ 2.0 ?).
> > >
> > > C Support
> > > ---------
> > > It is realized that current way of supporting C stubs and services
> has
> > > made the Axis C++ code too complicated. So we should refactor Axis
> C++
> > > so that the engine is independent of C support specific code.
> > >
> > > So we expect to do following regarding the C support. Assumption is
> that
> > > a developer always has a C++ compiler
> > > (no need of a linker)
> > >
> > > 1. Inside Axis C++ only new/delete is used (no malloc and free). Its
> > > usually not a problem to "delete" any memory allocated using malloc.
> > >     But the other way round may lead to memory leaks. But what about
> > > realloc when array deserialization ?.
> > > 2. Complex types are created as structs but is always wrapped by a
> C++
> > > class. Ex:-
> > >             typedef struct {
> > >                         int x;
> > >                         int y;
> > >         } Point;
> > >
> > >             Class PointWrapper : public ComplexType // ComplexType
> is an
> > > interface with serialization/deserialization functions
> > >             {
> > >             }
> > >             /* This PointWrapper will implement the
> > > serialization/deserialization/other functions of ComplexType
> interface
> > > */
> > > 3. Server side wrapper is C++ and the skeletons will be in C;
> > > 4. Client side stub is always C++ and a separate .cpp file is
> generated
> > > that has wrapping functions with C linkage.
> > > 5. Support for base types and extended types in WSDL (At the moment
> > > every extended type copies the attributes of base type ).
> > >
> > > Error handling
> > > --------------
> > > The performance gain we get by avoiding Exceptions is not worth the
> > > effort we spend for non-Exception based design. So We can
> > > decide to use Exception throughout the Axis C++ code. This will
> enable
> > > us to handle the error situations more easily. But
> > > we should take care to throw exceptions ONLY on an error situation
> (No
> > > catch and continue).
> > > 1. Improve the existing exception model
> > > 2. Introduce new exception classes where necessary
> > > 3. Introduce exceptions to all places in the Axis Code and handle
> every
> > > possible error.
> > > 4. Catch all exceptions by any C wrappers and return a meaningful
> error
> > > code to C client applications.
> > >
> > > XML Parser API
> > > --------------
> > > The existing parser API is not that good. We need to come up with an
> > > improved API for,
> > > 1. Optimized for SPP. Probably Typed Pull parser API.
> > > 2. Better white space handling,
> > > 3. Sequential querying based.
> > > 4. That supports DOM building.
> > > 5. May introduce the namespaces registering (see spp implementation)
> > >
> > > Then implement it by Expat/xerces and spp. The type conversion layer
> > > should be between deserializer and
> > > parser(Need to discuss and design this).
> > >
> > > SOAP Pull parser (SPP) Implementation
> > > ------------------
> > > The current txpp implementation should be added the namespace
> support
> > > and the type conversion layer. This type conversion layer may
> > > not be tightly coupled with rest of spp in order to use with xerces
> and
> > > expat. Introduce namespace registering mechanism.
> > >
> > > Transport Layers
> > > ----------------
> > > The existing transport API should be changed for following,
> > > 1. Avoid the use of the callback function. Let the transport handle
> > > buffers in its way.
> > > 2. The serializer should not concatenate the strings. Instead should
> > > send to the transport directly.
> > > 3. All buffers passed to transport in above 2 may not be null
> > > terminated. The size of the buffer/character should be passed.
> > > 4. Better timeout handling.
> > >
> > > Deserializer
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail