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 Mark Whitlock <ma...@uk.ibm.com> on 2004/11/19 12:59:12 UTC
Moving external header files
I am fixing AXISCPP-219 "Split client, server common includes" which moves
all the header files that are common to the client and server into
include/axis. I would like to agree which headers should be in which
directories before I start making changes. While I make the changes I would
like to internalise or delete header files where possible, so users are
only exposed to those methods/classes that work and are tested. So here is
my attempt at which header files belong where...
In include/axis...
Axis.hpp
AxisException.hpp
AxisGenException.hpp
AxisUserAPI.hpp
AxisWrapperAPI.hpp
BasicHandler.hpp
BasicNode.hpp
GDefine.hpp
Handler.hpp
IAttribute.hpp
IHandlerSoapSerializer.hpp
IHandlerSoapDeSerializer.hpp
IHeaderBlock.hpp
IMessageData.hpp
ISoapFault.hpp
IWrapperSoapDeSerializer.hpp
IWrapperSoapSerializer.hpp
SoapEnvVersions.hpp
TypeMapping.hpp
WSDDDefines.hpp
In include/axis/client...
Call.hpp
Stub.hpp
In include/axis/server...
WrapperClassHandler.hpp
Deleted...
- ISoapDeSerializer.hpp - this contains an empty class
- ISoapSerializer.hpp - this contains an empty class
- ISoapHeader.hpp - Call::setSoapHeader and
IHandlerSoapSerializer::setSoapHeader allow applications to pass in an
ISoapHeader, but ISoapHeader is an abstract class and there's no way for
the application to create one or get one back from another method. So it
seems that application cannot use ISoapHeader. so I propose to delete it. A
SoapHeader contains a list of HeaderBlocks. Applications want to get/set
HeaderBlocks using IHeaderBlock, rather than getting/setting a SoapHeader
using ISoapHeader.
Moved to src - internal only....
- IParam.hpp contains class IParam and class ComplexObjectHandler. Class
IParam seems to be redundant and could be removed. Class
ComplexObjectHandler is not needed externally and could be moved to
src/common/ComplexObjectHandler.h
- Packet.hpp could be moved to src/common except for
AXIS_TRANSPORT_INFORMATION_TYPE which would be moved to GDefine.hpp since
it is needed by Call.
Like last time I renamed header files, I will create the new headers,
leaving the old headers unchanged. Then update the source to include the
new headers. Then replace the contents of the old headers with a #error.
Then eventually delete the old headers.
Comments?
Mark
Mark Whitlock
IBM
Re: Moving external header files
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
+1.
Samisa...
Mark Whitlock <ma...@uk.ibm.com> wrote:
I am fixing AXISCPP-219 "Split client, server common includes" which moves
all the header files that are common to the client and server into
include/axis. I would like to agree which headers should be in which
directories before I start making changes. While I make the changes I would
like to internalise or delete header files where possible, so users are
only exposed to those methods/classes that work and are tested. So here is
my attempt at which header files belong where...
In include/axis...
Axis.hpp
AxisException.hpp
AxisGenException.hpp
AxisUserAPI.hpp
AxisWrapperAPI.hpp
BasicHandler.hpp
BasicNode.hpp
GDefine.hpp
Handler.hpp
IAttribute.hpp
IHandlerSoapSerializer.hpp
IHandlerSoapDeSerializer.hpp
IHeaderBlock.hpp
IMessageData.hpp
ISoapFault.hpp
IWrapperSoapDeSerializer.hpp
IWrapperSoapSerializer.hpp
SoapEnvVersions.hpp
TypeMapping.hpp
WSDDDefines.hpp
In include/axis/client...
Call.hpp
Stub.hpp
In include/axis/server...
WrapperClassHandler.hpp
Deleted...
- ISoapDeSerializer.hpp - this contains an empty class
- ISoapSerializer.hpp - this contains an empty class
- ISoapHeader.hpp - Call::setSoapHeader and
IHandlerSoapSerializer::setSoapHeader allow applications to pass in an
ISoapHeader, but ISoapHeader is an abstract class and there's no way for
the application to create one or get one back from another method. So it
seems that application cannot use ISoapHeader. so I propose to delete it. A
SoapHeader contains a list of HeaderBlocks. Applications want to get/set
HeaderBlocks using IHeaderBlock, rather than getting/setting a SoapHeader
using ISoapHeader.
Moved to src - internal only....
- IParam.hpp contains class IParam and class ComplexObjectHandler. Class
IParam seems to be redundant and could be removed. Class
ComplexObjectHandler is not needed externally and could be moved to
src/common/ComplexObjectHandler.h
- Packet.hpp could be moved to src/common except for
AXIS_TRANSPORT_INFORMATION_TYPE which would be moved to GDefine.hpp since
it is needed by Call.
Like last time I renamed header files, I will create the new headers,
leaving the old headers unchanged. Then update the source to include the
new headers. Then replace the contents of the old headers with a #error.
Then eventually delete the old headers.
Comments?
Mark
Mark Whitlock
IBM
---------------------------------
Do you Yahoo!?
The all-new My Yahoo! � Get yours free!