axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Whitlock <mark_whitl...@uk.ibm.com>
Subject Fw: 1.4 - Header file restructuring [WAS :Re: RE: Re: 1.3 release]
Date Wed, 20 Oct 2004 11:39:20 GMT




+1 to reorganising the directory structure.
+1 to not shipping Packet.h and other xmlparser/transport internal
interfaces
AXISCPP-190 and AXISCPP-191 touch on smaller inconsistencies with the
directory structure

I think ISoapSerializer.h and ISoapDeSerializer.h should be removed
internally and externally since they are empty classes, unless someone is
intending to implement something more in them. IWrapperSoapSerializer.h and
IWrapperSoapDeSerializer.h still need to be shipped to enable generated
stubs to serialize and deserialize complex types. Although maybe
IWrapperSoapSerializer.h could be renamed ISoapSerializer.h and
IWrapperSoapDeSerializer.h could be renamed ISoapDeSerializer.h?

Also most of WSDDDefines.h, TypeMapping.h and SoapEnvVersions.h does not
need to be externalised. Can we move these inside src as well?
Mark
Mark Whitlock
IBM

--- John Hawkins <HAWKINSJ@uk.ibm.com> wrote:

> >1. At the moment few headders common to both client and server are in
> include/axis/server. We got
> to move them to include/axis
> Not sure what you mean here?

Headers such as BasicNode.h AxisException.h GDefine.h IHeaderBlock.h are
used both by server side
as well as client side. However they are in include/axis/server. As they
are not server specific,
should be in include/axis.

>
> >2. As Mark have identified in a Jira issue we have to remove some
headers
> with empty classes etc.
> +1
>
> >3. Parser (XMLParser.h) and transport (SOAPTransport.h) abstraction
layer
> headers are hidden
> inside src. I guess we go to ship those headers, so that if users want
they
> can extend and write
> their own parser/transport libs. Hence move them to include/axis
>
> "users" in this case are developers not "service writers". very few
people
> want to write their own abstraction layers so I vote -1 to shipping
> "internal" interfaces. If someone wants to write this much code they
should
> be an Axis developer or download extra files.

OK. In this case we have to move ISoapDeSerializer.h, ISoapSerializer.h,
IWrapperSoapDeSerializer.h , IWrapperSoapSerializer.h and Packet.h to
src/soap as they are
internal interfaces.

Samisa...

>
> John Hawkins
>
>
>
>
>

>              Samisa Abeysinghe

>              <samisa_abeysingh

>              e@yahoo.com>
To
>                                        Apache AXIS C Developers List

>              20/10/2004 07:40          <axis-c-dev@ws.apache.org>

>
cc
>

>              Please respond to
Subject
>               "Apache AXIS C           1.4 - Header file restructuring

>              Developers List"          [WAS :Re: RE: Re: 1.3 release]

>

>

>

>

>

>

>
>
>
>
> Mark wrote:
> > So after 1.3 is shipped I intend to rename the existing external C++
> header
> > files to .hpp. So Call.h will become Call.hpp (without the C support in
> it). In 1.5
> > Call.h will reappear as a C-only header file.
>
> As part of this we could clean up the current header file structure.
>
> 1. At the moment few headders common to both client and server are in
> include/axis/server. We got
> to move them to include/axis
> 2. As Mark have identified in a Jira issue we have to remove some headers
> with empty classes etc.
> 3. Parser (XMLParser.h) and transport (SOAPTransport.h) abstraction layer
> headers are hidden
> inside src. I guess we go to ship those headers, so that if users want
they
> can extend and write
> their own parser/transport libs. Hence move them to include/axis
>
> Thoughts please...
>
> Samisa...
>
>
> --- Samisa Abeysinghe <samisa_abeysinghe@yahoo.com> wrote:
>
> > I think this has been already discussed in much depth.
> >
> > The Jira issues on those also have details on this.
> >
> > You could review the comments on Jira and add you comments on Jira
> itself.
> >
> > Samisa...
> >
> > sanjaya singharage <sanjayas@opensource.lk> wrote:
> > Shall we have a more detailed and technical discussion on "how" C
support
> is
> > to be eliminated and how to reintroduce it back? Better start a new
> thread
> > on it.
> >
> > sanjaya.
> >
> >
> > ----- Original Message -----
> > From: "Mark Whitlock"
> > To:
> > Sent: Tuesday, October 19, 2004 6:24 PM
> > Subject: Fw: RE: Re: 1.3 release
> >
> >
> > >
> > >
> > >
> > >
> > > Once 1.3 has shipped I intend to remove all the C support. Then make
> the
> > > engine pure C++ which means changing all the mallocs/frees/strdups to
> > > news/deletes and changing structs to classes, where possible. I won't
> add
> > > in any STL strings to the external API, but I may use STL strings
> > > internally where it makes sense (e.g. AxisConfig.cpp). I will make it
> > clear
> > > in the API documentation who (Axis or the application) owns the
storage
> > > that is returned from the Axis APIs, so it is easier for applications
> to
> > > avoid memory leaks. I will attempt to fix memory leaks in the engine,
> as I
> > > review the lifecycle of these objects. There are a bunch of JIRAs
that
> I
> > > hope to fix along the way such as 190, 191, 202 and 207.
> > >
> > > In 1.5, I will add back in C support. As was agreed in a previous
> thread,
> > > the new C support would be contained in separate header files, source
> > files
> > > and built into a separate library which C applications could link
> against.
> > > The current C bindings for the dynamic client API are awkward for C
> > > programmers to use and need rework. I will discuss major changes on
the
> > > mailing list to get general agreement.
> > >
> > > Samisa suggested, I agreed and no one disagreed that the C support
> should
> > > be in .h header files and the C++ support should be in .hpp files. So
> > after
> > > 1.3 is shipped I intend to rename the existing external C++ header
> files
> > to
> > > .hpp. So Call.h will become Call.hpp (without the C support in it).
In
> 1.5
> > > Call.h will reappear as a C-only header file.
> > >
> > > I may create a "sandpit" branch so that I can try out the reworked C
> > > bindings before externalising them in 1.5. I am primarily focussing
on
> the
> > > client, but I need to make sure that I don't break the server as I
go.
> > > Mark
> > > Mark Whitlock
> > > IBM
> > >
> > > ----- Forwarded by Mark Whitlock/UK/IBM on 10/19/2004 11:58 AM -----
> > >
> > > damitha@opensourc
> > > e.lk
> > > To
> > > 10/19/2004 09:09 "Apache AXIS C Developers List"
> > > AM
> > > cc
> > >
> > > Please respond to Subject
> > > "Apache AXIS C RE: Re: 1.3 release
> > > Developers List"
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Yes a rewriting would be easier. Practically it is very difficult to
> merge
> > > back when there is lot of changes
> > >
> > > thanks
> > > damitha
> > >
> > > > I do not think that we would be able to branch 1.3 and then later
> merger
> > > > with 1.5 on C stuff.
> > > >
> > > > This is because, with the proposed wrapper approach in 1.5 for C
> > support,
> > > > the API though which the
> > > > C client/services talk to the main engine would change
considerably.
> > > Hence
> > > > I doubt the
> > > > possibilities of merging. Rather than try and merge, a rewrite
would
> be
> > > > easier, I guess.
> > > >
> > > > Samisa...
> > > >
> > > > --- Farhaan Mohideen wrote:
> > > >
> > > >> Hi Mark;
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


Mime
View raw message