Migration from this wiki may have to happen sometime. In the mean time please continue to use. (MigrateFromThisWiki)
Axis C++ TODO List
''This is the wiki page for the Axis C++ TODO List.
The page is set out so that features are allocated to releases of code. At the bottom there are features that are currently wish-list but these can be moved into a release if you have the time to do them 
Each release feature list is laid out in order of approximate priority such that the bottom feature is first to drop out if it can not be accomodated in the that release. During every release we should ensure that all major bugs are fixed as well as adding new features
Release 1.4 (Target Late november 2004)
1. Create 100% C++ engine - [[http://nagoya.apache.org/jira/browse/AXISCPP-206|AXISCPP-206]]
- We'll do this by removing C++ Support for this release then adding it back in 1.5.
2. Refactor [[WSDL2WS]] - [[http://nagoya.apache.org/jira/browse/AXISCPP-215|AXISCPP-215]]
- This is pretty much open-ended - Anything we can do here is good !
3. Improve Fault handling - [[http://nagoya.apache.org/jira/browse/AXISCPP-216|AXISCPP-216]]
- We built a much better fault handling mechanism in 1.2 but this can be improved now that we have user feedback
4. IPV6 - [[http://nagoya.apache.org/jira/browse/AXISCPP-217|AXISCPP-217]]
Microsoft has a windows tool - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/using_the_checkv4_exe_utility_2.asp
5. WSI BP 1.0 compatible - [[http://nagoya.apache.org/jira/browse/AXISCPP-218|AXISCPP-218]]
- Automate ws-i profile in tests to ensure compliance and then alter code accordingly
6. Include file refactoring - [[http://nagoya.apache.org/jira/browse/AXISCPP-219|AXISCPP-219]]
- This is to ensure the that a client stub writer only has to include the "client" includes, service writers the "server" and common goes in "common".
7. Create SSL implementation
- We currently have an out of date ssl impl we would like to improve it to work with the current transport.
8. Remove pre-defined paths from Axis CPP Conf library names - [[http://nagoya.apache.org/jira/browse/AXISCPP-220|AXISCPP-220]]
9. Eliminate warnings [[http://nagoya.apache.org/jira/browse/AXISCPP-155|AXISCPP-155]]
- We have a lot of compile warnings which need to be verified to ensure they're not problems and then removed if possible.
10. Improve Makefiles [[http://nagoya.apache.org/jira/browse/AXISCPP-221|AXISCPP-221]]
- Currently we store makefile.in. this is causing us problems. Rethink policy
11. Prepare tutorial on Handlers and update the Architecture Guide
12. Add href/multiref support [[http://nagoya.apache.org/jira/browse/AXISCPP-111|AXISCPP-111]]
13. Add Pull parser
#Our clients are also like to have this as soon as possible and then no need to associate other parsers. #For the moment we are using a wrapper around other third party parsers and have made them work as a pull parser but they are not actual pull parsers.
14. Add Session support
Session maintanance is only partially implemented.
Cookie based session support is completed for client side and it works now with axis2 transport. This would be available with 1.4 release. Axis C++ is now capable of working with Axis Java services with Cookie based session enabled. AXISCPP-226
Have to support Cookie based session support on server side AXISCPP-246. (most probably in 1.5)
We also have SOAP Header based session handling AXISCPP-238. This is planed for 1.4.
=== 15. Implement WS-Attachments ===
16. Support WS-Security & WS-Addressing requirements
#This is laying the ground so that WS-Security and WS-adressing can be tackled at a later date or by other developers. It is not putting in support to this release.
Release 1.5 (Target Late January)
1. C support - [[http://nagoya.apache.org/jira/browse/AXISCPP-210|AXISCPP-210]]
Put back into WSDL2WS C wrappers for the new 100% C++ engine Put back C client/server samples disabled in 1.4 AXISCPP-235
2. Memory clean-up and fix - [[http://nagoya.apache.org/jira/browse/AXISCPP-149|AXISCPP-149]]
- As it says - run a memory management tool and tackle issues that come out of it. This should be done after the C support has been put back in.
3. Improve HTTP Support - [[http://nagoya.apache.org/jira/browse/AXISCPP-176|AXISCPP-176]]
Fix outstanding issues with HTTP support in the new transport layer. AXISCPP 176 is just one of many we can do?
4 Improvement of Web-site.
- Web-site should be made more like Axis-Java website for ease of use.
- More user oriented and less developer oriented.
- Fault mapping (Stub level)
- Add support for xsd:any type
- Ability to add custom headers to SOAP messages
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Not in plan <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
These are not in any order.
1).Transport
Axis transport layer should be improved to support following features.
#Implementation of XIO transport layer for axis. #Implementation of Axis ISAPI extension to use Axis with Microsoft IIS. #Supporting two types of transport APIs.(decided at compile time)
- The two APIs are,
- Transport layer allocates received buffers and pass 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.
- To receive data Axis provides a buffer to the transport 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.
- For each of above APIs Axis should provide interfaces and/or C function pointer table definition (like "module" in apache modules)
2).WSDD
#Implementation of serialize methods to every WSDD class for writing WSDD file from the memory representation (this feature is required for dynamic deployment/undeployment). #Explore the situation 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. #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.
3). C/C++ API for XML RPC (CAx-RPC)
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.
4). Standard Handlers
Axis should implement set of standard handlers for following purposes. #Ws-Security #Ws-Transaction #Ws-Routing
5). New features to Add
#SOAP with attachments - mTOM #Add more functionality to Admin service and client. #Add RPC literal support if needed. #Add 2 API functions to the generated services
#Add new API functions to the CallBase and Wrappers for accessing Axis trace logger. Then the code generation can also be improved to log errors. Handler writers can use this API to write to Axis logger (such as apache has provided module API functions to write to apache log files).
6). Architecture/Code reviews
#Software architects/developers should be invited to review the architecture and the code of Axis and get their feedback. #As the service file decides whether it is a C or C++ service by populating either _functions or _objects, We can omit C or CPP from the value of the "provider" attribute of a service entry in server.wsdd. But we should check the code to find whether there is any other impact.
7). 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.
8). Support for internationalization
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.
9). [[WSDL2WS]] code generation
#Replacing code in service loader file with predefined Macros. These macros should be predefined in one of the header files of Axis. #Removing the restriction in WSDL2Ws tool on processing very BIG wsdls (timeout issue). #Improving the WSDL2Ws tool to,
Get the wsdl from a url (as in WSDL2Java tool)
- Generate code for all portTypes of a wsdl .
10). Security
#Support SOAP-level security according to existing security SOAP-level standards.