RE: Axis C++ todo list

[Kanchana Welagedara <ka...@opensource.lk>]

Hi!

I would like to add followings in todo list

1.Adminclient
2.Documentation Update with using Expact parser alternatively to xerces
Thanks
Kanchana


> -----Original Message-----
> From: susantha@opensource.lk [mailto:susantha@opensource.lk]
> Sent: Thursday, February 12, 2004 11:47 AM
> To: axis-c-dev@ws.apache.org
> Cc: axis-c-user@ws.apache.org
> Subject: Axis C++ todo list
>
>
> Hi All,
>
> I have prepared a TODO list for Axis C++. The content in this list is
> based on my knowladge/ideas of Axis and recent discussions held with Axis
> C++ team. Please feel free to suggest/criticize them.
>
> I wish we start discussion threads on each of the items so that all
> developers understand the task to ensure that all proceed the the correct
> direction.
>
> Then each contributor can choose a particular area to develop.
>
> I know few of these work have already been done and some are in progress.
> Please let others know what of these have been done already and what are
> in progress.
>
> Also we have to take a decision on the set of items we consider for next
> release of Axis C++ (release 1.1 is planned to the first week of March
> 2004).
>
> This TODO list is available at wiki page
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?AxisCpp_TODO
>
> Thanks,
>
> Susantha.
>
>                                 Axis C++ TODO List
> ==================================================================
> ==========
>
> 1).Transport
> ============
> Axis transport layer should be improved to support following features.
>
> 1. Both http chunked and http unchunked data transfer
> 2. Support for plug-in other kind of trasport layers (SMTP etc).
> 3. Making the transport layer a separate DLL at client side. Then this DLL
> is loaded by Axis Client library.
> 4. Using libWWw for axis transport layer.
> 5. Implementaion of XIO transport layer for axis.
> 6. Supporting two types of transport APIs.(decided at compile time)
>
> 	- The two APIs are,
>
> 	a. Transport layer allocates receive buffers and passed to
> Axis. buffers
> to send are allocated by Axis
> 	   and passed to trasport layer to be sent. There can be
> multiple buffers
> passed to / from Axis for a
> 	   single request. This API is suitable for non-blocking transport
> layers. Example for this kind of
> 	   transport is XIO.
>
> 	b. To receive data Axis provides a buffer to the trasport
> layer and the
> transport layer fills and returns
> 	   it back to Axis. To send data Axis passes a buffer to
> the transport
> layer. There is only one buffer in
> 	   each way (per thread). The two buffers are allocated by
> Axis and may
> be re-used within a single request.
> 	   Essentially Axis blocks when the transport layer
> processes. But as
> this API (model) best fits the XMLPull
> 	   parsing model, this should be the default API.
>
> 	- Providing ineterfaces for C and C++ transport layers.
>
> 	For each of above APIs Axis should provide interfaces
> and/or C function
> pointer table definition (like "module"
> 	in apache modules)
>
> 7. Implementaion of Axis ISAPI extension to use Axis with Microsoft IIS.
>
> 2).Source Restructuring
> =======================
>
> 1. Include files should be restructured in the CVS folder hiarachy to keep
> include files that goes with binary
>    distribution seperately. Then CVS folder /c/include will contain only
> the include files that goes with binary
>    distribution and all other include files are moved to the respective
> /c/src folder. Following structure is to
>    be adopted for /c/include folder.
>
>    /c
>     |--client
>     |     |--libwww
>     |     |--axis
>     |     |--xio
>     |--server
>     |     |--apache1_3
>     |     |--apache2_0
>     |     |--iis
>
>
> 3). Build environments
> ======================
>
> 1. Distribution build files. Rather than building each project and
> manually copying the files to prepare the
>    distribution we need to have build files (Makefiles, Visual C++ build
> files, other) to automate this process.
> 2. Eclipse CDT projects and/or build files
> 3. Borland C projects and/or build files
> 4. Unittests /unittest/cppunit
>
> 4).Client Engine
> ================
>
> 1. Implementation of client Side handler processing.
> 2. Making Axis client a common DLL so that any (all) client application(s)
> use the same Axis client DLL. Then the
>    generated stubs are not compiled with all Axis code. But minimum code
> that can load the client Axis DLL.
>
> 5).Server Engine
> ================
> 1. Making Axis server a common DLL so that any server side module can use
> the same Axis DLL (apache module, ISAPI,
>    JNI, XIO or SimpleAxisServer etc).
>
> 6).Serialization / Deserialization
> ==================================
> 1. Axis source at CVS head does not support parsers other than Expat. We
> need to write wrappers for using xerces/libxml/txpp
> 2. Implementation of the basic XMLPull parser for Axis.
> 3. Axis have to come up with an architecture to support extensible types
> and #any types.
>
> 7).WSDD
> =======
> 1. Axis source code at CVS uses only Expat parser to parse WSDD file.We
> have to define Interfaces and wrappers for supporting
>    other parsers (xerces/libxml/txpp).
> 2. Implementation of serialize methods to every WSDD class for writing
> WSDD file from the memory representation (this
>    feature is required for dynamic deployment/undeployment).
> 3. Explore the situattion when multiple clients or servers work with same
> wsdd. Either we have to workout a way to have
>    a single WSDD for each server/client application or have separate
> sections in the same WSDD for each server/client.
> 4. Studying other facilities of wsdd schema and changing/modifying it to
> fit Axis C++.
>    At the moment Axis C++ uses the same WSDD schema designed for Axis
> Java. But IMO we have the freedom to customize it
>    to fit Axis C++ requirements. Ex: typeMapping and beanMapping sections.
>
> 8).Error Handling
> =================
> 1. At the moment Axis uses only 2 global error codes (AXIS_SUCCESS and
> AXIS_FAIL) and hence when an error occured not
>    enough information is returned back to where the error is handled. SO
> we have to define a global flat list of errors
>    and propagate enough information about the error.
> 2. In Axis not all the code base handle every possible error situations.
> Also there are places where the same error is
>    checked more than onece. We have to avoid these trivial error
> checkings.
>
> 9). C/C++ API for XML RPC (CAx-RPC)
> ===================================
> 1. Axis C++ team has to come up with a draft document for "C/C++ API for
> XML RPC". Also all interested parties should
>    be invited to participate.
>
> 10).Standard Handlers
> =======================
> Axis should implement set of standard handlers for following purposes.
> 	a. Ws-Security
> 	b. Ws-Transaction
> 	c. Ws-Routing
>
> 11).New featurs to Add
> =========================
> 1. SOAP with attachements.
>
> 12). Architecture/Code reviews
> ==============================
> Software architects/developers should be invited to review the
> architecture and the code of Axis and get thier feedback.
>
> 13). Tutorial preparation
> =========================
> Axis has to prepare 2 sets of comprehensive tutorials on using Axis server
> and client library. Step by step guide on both
> Windows and Linux platforms.
>
> 14). Performance tuning
> =======================
> 1. Minimizing the usage of STL.
> 2. Remove the trivial code. Ex: Param class and ArrayBean class
> 3. Avoid trivial error checking.
>
> 15). Support for internationalization
> =====================================
> 1. Providing 2 different Axis libraries for utf-8 and utf-16
> applications/services. we have to have a compiler
>    directive to decide what the output encoding is.
>
> 16). WSDL2WS code generation
> ============================
> 1. Code generation to handle fault messages
> 2. C/C++ names of Complex types should be fully qualified to avoid name
> collisions.
>    Ex: http___www_opensource_lk_MyType instead of Mytype
> 3. Code generation for Extensible types and #any type support.
>
> 17). Session support
> ====================
> Even if the Axis code base written to handle sessions, non of the
> transport modules use that feature (both client and server).
>
> 18). Security
> =============
> 1. Support transport-level security (SSL etc).
> 2. Support SOAP-level security according to existing security SOAP-level
> standards.
>
> 19). Code improvements
> ======================
> 1. Praparing a coding standard guidelines document for Axis C++.
> 2. Applying those coding standards to the existing code base.
>
>
>
>
>

RE: Axis C++ todo list

[su...@opensource.lk]

Yes please..

> Hi!
>
> I would like to add followings in todo list
>
> 1.Adminclient

I think the proper place to add this is under section
11).New featurs to Add

> 2.Documentation Update with using Expact parser alternatively to xerces

We may need to add new section for Documentation

Thanks,

Susantha.