You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by damitha kumarage <da...@opensource.lk> on 2004/07/15 11:37:59 UTC
Meeting with Alex
Hi,
Some of the Axis C++ developers at Lanka Software Foundation had
some meetings during the past days of the week. The topics discussed
were
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
solutions.
* We need to add more error handling code in SoapDeserializer and other
places
* Use logging facility more in the Axis C++ engine(To log exception
situations)
* 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
the
purpose of seraizaiton and deserialization instead reinventing the
wheel.
* We could use Axis C++ transport handlers as wrappers to different
transport libraries to wrap different
functionlities.
* 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
etc.
* We could use Axis C++ transport handlers as wrappers to different
transport libraries to wrap different functionlities.
regds,
damitha
Re: Meeting with Alex
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
A few comments:
"damitha kumarage" <da...@opensource.lk> writes:
> Some of the Axis C++ developers at Lanka Software Foundation had
> some meetings during the past days of the week. The topics discussed
> were
Not Alex .. Alek Slominski .. who is visiting Sri Lanka right now :).
> * 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)
The requirement is to support pure C stubs and skeletons. As you noted
skeletons are easy .. then its C++ calling C. Pure C stubs is what's
a bit of a pain.
> * 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
> solutions.
Can we not do everything in C++ and then provide a bridge layer for
the API that the C stubs use to talk to the engine?
> * 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.
Why is it necessary to avoid STL for the engine and for C++ stubs?
Of course the C stubs can't use STL.
> * In the soap pull parser think first of a good API that will
> not change over the time.
+1. How is that API different from the parser abstraction API that
exists now?
> 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.
I disagree (see next comment).
> Note: If Axis C++ support other parsers we need to have
> the type conversion layer in Axis C++ any way.
Not in Axis/C++ .. but a utility library for integration un-typed
parsers. That is, the engine can still speak to the parser via the
typed pull interface, but the the parser itself would be wrapped by
that layer before it does its work. In the native case that wrapper
layer (which is what we have now) will not be necessary.
> * It is better if the parser could be written in C++ because of
> the language features of C++ such as better exception handling
+1.
> * We could use Axis C++ transport handlers as wrappers to different
> transport libraries to wrap different functionlities.
+1.
Sanjiva.
Re: Meeting with Alex
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
A few comments:
"damitha kumarage" <da...@opensource.lk> writes:
> Some of the Axis C++ developers at Lanka Software Foundation had
> some meetings during the past days of the week. The topics discussed
> were
Not Alex .. Alek Slominski .. who is visiting Sri Lanka right now :).
> * 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)
The requirement is to support pure C stubs and skeletons. As you noted
skeletons are easy .. then its C++ calling C. Pure C stubs is what's
a bit of a pain.
> * 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
> solutions.
Can we not do everything in C++ and then provide a bridge layer for
the API that the C stubs use to talk to the engine?
> * 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.
Why is it necessary to avoid STL for the engine and for C++ stubs?
Of course the C stubs can't use STL.
> * In the soap pull parser think first of a good API that will
> not change over the time.
+1. How is that API different from the parser abstraction API that
exists now?
> 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.
I disagree (see next comment).
> Note: If Axis C++ support other parsers we need to have
> the type conversion layer in Axis C++ any way.
Not in Axis/C++ .. but a utility library for integration un-typed
parsers. That is, the engine can still speak to the parser via the
typed pull interface, but the the parser itself would be wrapped by
that layer before it does its work. In the native case that wrapper
layer (which is what we have now) will not be necessary.
> * It is better if the parser could be written in C++ because of
> the language features of C++ such as better exception handling
+1.
> * We could use Axis C++ transport handlers as wrappers to different
> transport libraries to wrap different functionlities.
+1.
Sanjiva.