axis-c-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From damitha kumarage <>
Subject Meeting with Alex
Date Thu, 15 Jul 2004 09:37:59 GMT

    Some of the Axis C++ developers at Lanka Software Foundation had
some meetings during the past days of the week. The topics discussed

Axis C++ :thoughts on improvments
Pull parser model
Open Source development
Here are some of the things we discussed
* It may not be a good idea of supporting both C and C++ concurrently.
It is important to analyze the actual requirements for a pure C web
service engine. Since
the server side  C services can always be wrapped as C++ services we
need not have a server side C only web service engine.

  But for client side it may be important to have a separate C and C++
client engines or a mixed one(like it is now)

* In C only web service engine error handling is difficult. We need to
consider every exception situation.
  Also function pointer passing like things are complex than having a
clean OOP solutions like deriving from a base class
  So If we avoid C code in Axis C++ engine we can give cleaner
                                   * We need to add more error handling code in SoapDeserializer
and other

* Use logging facility more in the Axis C++ engine(To log exception
* Using STL may actually make the memory foot print smaller. Also you
can have type safety. STL maps and strings could be the most efficient
and tested.
Only valid reason to avoid STL is going for pure C.
* Use an existing transport library as the default client transport for
Axis C++ client engine which is well tested for performance and features
* Don't create and keep Axis Engine serialize buffers. Write the
  content directly in to apache(or whatever server side
  tranport) so that buffering is done in an optimized way by that
  transport. In client side also let the buffering, compression, ssl
support etc.
  to be done by a good well tested transport library.
  Don't waste the time writing transport libraries. People expect
  good Axis C++ engine which do its intended job well.

  Also think of using existing good serializers and deserializers for
  purpose of seraizaiton and deserialization instead reinventing the
* We could use Axis C++ transport handlers as wrappers to different
  transport libraries to wrap different         
* In the soap pull parser think first of a good API that will
  not change over the time. Typed pull parser can be implemented
  on top of a pull parser. Don't try to create a typed pull parser
  that directly convert into the type from the byte stream,
  before first testing the performance gain.
  Note: If Axis C++ support other parsers we need to have
        the type conversion layer in Axis C++ any way.

* It is better if the parser could be written in C++ because of
  the language features of C++ such as better exception handling
* We could use Axis C++ transport handlers as wrappers to different
  transport libraries to wrap different functionlities.

View raw message