axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <sanj...@opensource.lk>
Subject Re: Meeting with Alex
Date Fri, 16 Jul 2004 01:58:23 GMT
A few comments:

"damitha kumarage" <damitha@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.


Mime
View raw message