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 Samisa Abeysinghe <sa...@yahoo.com> on 2004/10/20 08:40:00 UTC
1.4 - Header file restructuring [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 <sa...@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 <sa...@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;
> > >>
> > >> I was following your thread on cleaning up the engine code so as to
> make
> > >> it
> > >> pure C++. In 1.4 if you were to remove C support and then include it
> > >> back in
> > >> 1.5 by when are we expecting to ship 1.5? This would also mean that we
> > >> should branch at 1.3 and then converge if all goes well in 1.5.
> > >>
> > >> Regards
> > >> Farhaan
> > >>
> > >> -----Original Message-----
> > >> From: Mark Whitlock [mailto:mark_whitlock@uk.ibm.com]
> > >> Sent: 18 October 2004 19:31
> > >> To: axis-c-dev@ws.apache.org
> > >> Subject: Fw: Re: 1.3 release
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> I'm keen that 1.3 gets shipped soon, as I would like to start making
> > >> changes for 1.4 (C/C++ bindings, etc) but I don't want to make these
> > >> changes until 1.3 is shipped as it would destabilise the code.
> > >> Mark
> > >>
> > >> > >
> > >> > > Hi Folks,
> > >> > >
> > >> > > the 1.3 release has not been declared.
> > >> > > What are the latest schedules ?
> > >> > > Are we waiting on any bugs to be fixed?
> > >> >
> > >> > linux user guide is obsolete. Need to update it. I'm going to fix it
> > >> > tomorrow earliest
> > >> >
> > >> > thanks
> > >> > damitha
> > >> > >
> > >> > >
> > >> > >
> > >> > > John Hawkins
> > >> > >
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > > _______________________________
> > > Do you Yahoo!?
> > > Declare Yourself - Register online to vote today!
> > > http://vote.yahoo.com
> > >
> > >
> >
> >
> >
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> vote.yahoo.com - Register online to vote today!
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Re: 1.4 - Header file restructuring [WAS :Re: RE: Re: 1.3 release]
Posted by da...@opensource.lk.
Hi,
> 1. what are these common headers?
Common headers mean headers common to both server and client engine
>
> 3. +1 to moving XMLParser.h and SOAPTransport.h to include/axis
> (would there be an advantage in placing them in include/axis/parser and
> include/axis/transport ?)
We have decided not to use a tree structure earlier. The current somewhat
flat structure is ok. Only branches are client and server.
thanks
damitha
>
> sanjaya.
>
> ----- Original Message -----
> From: "Samisa Abeysinghe" <sa...@yahoo.com>
> To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
> Sent: Wednesday, October 20, 2004 12:40 PM
> Subject: 1.4 - Header file restructuring [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 <sa...@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 <sa...@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;
>> > > >>
>> > > >> I was following your thread on cleaning up the engine code so as
>> to
>> > make
>> > > >> it
>> > > >> pure C++. In 1.4 if you were to remove C support and then include
> it
>> > > >> back in
>> > > >> 1.5 by when are we expecting to ship 1.5? This would also mean
>> that
> we
>> > > >> should branch at 1.3 and then converge if all goes well in 1.5.
>> > > >>
>> > > >> Regards
>> > > >> Farhaan
>> > > >>
>> > > >> -----Original Message-----
>> > > >> From: Mark Whitlock [mailto:mark_whitlock@uk.ibm.com]
>> > > >> Sent: 18 October 2004 19:31
>> > > >> To: axis-c-dev@ws.apache.org
>> > > >> Subject: Fw: Re: 1.3 release
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >> I'm keen that 1.3 gets shipped soon, as I would like to start
> making
>> > > >> changes for 1.4 (C/C++ bindings, etc) but I don't want to make
> these
>> > > >> changes until 1.3 is shipped as it would destabilise the code.
>> > > >> Mark
>> > > >>
>> > > >> > >
>> > > >> > > Hi Folks,
>> > > >> > >
>> > > >> > > the 1.3 release has not been declared.
>> > > >> > > What are the latest schedules ?
>> > > >> > > Are we waiting on any bugs to be fixed?
>> > > >> >
>> > > >> > linux user guide is obsolete. Need to update it. I'm going to
>> fix
> it
>> > > >> > tomorrow earliest
>> > > >> >
>> > > >> > thanks
>> > > >> > damitha
>> > > >> > >
>> > > >> > >
>> > > >> > >
>> > > >> > > John Hawkins
>> > > >> > >
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > _______________________________
>> > > > Do you Yahoo!?
>> > > > Declare Yourself - Register online to vote today!
>> > > > http://vote.yahoo.com
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> >
>> > ---------------------------------
>> > Do you Yahoo!?
>> > vote.yahoo.com - Register online to vote today!
>>
>>
>>
>>
>> _______________________________
>> Do you Yahoo!?
>> Declare Yourself - Register online to vote today!
>> http://vote.yahoo.com
>>
>
>
>
>
Re: 1.4 - Header file restructuring [WAS :Re: RE: Re: 1.3 release]
Posted by sanjaya singharage <sa...@opensource.lk>.
1. what are these common headers?
3. +1 to moving XMLParser.h and SOAPTransport.h to include/axis
(would there be an advantage in placing them in include/axis/parser and
include/axis/transport ?)
sanjaya.
----- Original Message -----
From: "Samisa Abeysinghe" <sa...@yahoo.com>
To: "Apache AXIS C Developers List" <ax...@ws.apache.org>
Sent: Wednesday, October 20, 2004 12:40 PM
Subject: 1.4 - Header file restructuring [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 <sa...@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 <sa...@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;
> > > >>
> > > >> I was following your thread on cleaning up the engine code so as to
> > make
> > > >> it
> > > >> pure C++. In 1.4 if you were to remove C support and then include
it
> > > >> back in
> > > >> 1.5 by when are we expecting to ship 1.5? This would also mean that
we
> > > >> should branch at 1.3 and then converge if all goes well in 1.5.
> > > >>
> > > >> Regards
> > > >> Farhaan
> > > >>
> > > >> -----Original Message-----
> > > >> From: Mark Whitlock [mailto:mark_whitlock@uk.ibm.com]
> > > >> Sent: 18 October 2004 19:31
> > > >> To: axis-c-dev@ws.apache.org
> > > >> Subject: Fw: Re: 1.3 release
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> I'm keen that 1.3 gets shipped soon, as I would like to start
making
> > > >> changes for 1.4 (C/C++ bindings, etc) but I don't want to make
these
> > > >> changes until 1.3 is shipped as it would destabilise the code.
> > > >> Mark
> > > >>
> > > >> > >
> > > >> > > Hi Folks,
> > > >> > >
> > > >> > > the 1.3 release has not been declared.
> > > >> > > What are the latest schedules ?
> > > >> > > Are we waiting on any bugs to be fixed?
> > > >> >
> > > >> > linux user guide is obsolete. Need to update it. I'm going to fix
it
> > > >> > tomorrow earliest
> > > >> >
> > > >> > thanks
> > > >> > damitha
> > > >> > >
> > > >> > >
> > > >> > >
> > > >> > > John Hawkins
> > > >> > >
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________
> > > > Do you Yahoo!?
> > > > Declare Yourself - Register online to vote today!
> > > > http://vote.yahoo.com
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> >
> > ---------------------------------
> > Do you Yahoo!?
> > vote.yahoo.com - Register online to vote today!
>
>
>
>
> _______________________________
> Do you Yahoo!?
> Declare Yourself - Register online to vote today!
> http://vote.yahoo.com
>
Re: 1.4 - Header file restructuring [WAS :Re: RE: Re: 1.3 release]
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
--- Adrian Dick <ad...@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?
>
> Am I right in thinking the intention is to correctly re-organise to become:
> include/axis - Common to client and server
> include/axis/server - Server only
> include/axis/client - Client only
Correct!
Samisa...
>
> In which case +1
>
> >
> > >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
> >
> As John mentioned, this isn't something we'd expect service writers to be
> doing, so I also say -1.
>
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Re: 1.4 - Header file restructuring [WAS :Re: RE: Re: 1.3 release]
Posted by Adrian Dick <ad...@uk.ibm.com>.
>
> >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?
Am I right in thinking the intention is to correctly re-organise to become:
include/axis - Common to client and server
include/axis/server - Server only
include/axis/client - Client only
In which case +1
>
> >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
>
As John mentioned, this isn't something we'd expect service writers to be
doing, so I also say -1.
Re: 1.4 - Header file restructuring [WAS :Re: RE: Re: 1.3 release]
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
--- John Hawkins <HA...@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
>
> >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.
>
> John Hawkins
>
>
>
>
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com> To
> Apache AXIS C Developers List
> 20/10/2004 07:40 <ax...@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 <sa...@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 <sa...@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!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Re: 1.4 - Header file restructuring [WAS :Re: RE: Re: 1.3 release]
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
--- John Hawkins <HA...@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 <ax...@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 <sa...@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 <sa...@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
Re: 1.4 - Header file restructuring [WAS :Re: RE: Re: 1.3 release]
Posted by John Hawkins <HA...@uk.ibm.com>.
>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?
>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.
John Hawkins
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
20/10/2004 07:40 <ax...@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 <sa...@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 <sa...@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;
> > >>
> > >> I was following your thread on cleaning up the engine code so as to
> make
> > >> it
> > >> pure C++. In 1.4 if you were to remove C support and then include it
> > >> back in
> > >> 1.5 by when are we expecting to ship 1.5? This would also mean that
we
> > >> should branch at 1.3 and then converge if all goes well in 1.5.
> > >>
> > >> Regards
> > >> Farhaan
> > >>
> > >> -----Original Message-----
> > >> From: Mark Whitlock [mailto:mark_whitlock@uk.ibm.com]
> > >> Sent: 18 October 2004 19:31
> > >> To: axis-c-dev@ws.apache.org
> > >> Subject: Fw: Re: 1.3 release
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> I'm keen that 1.3 gets shipped soon, as I would like to start making
> > >> changes for 1.4 (C/C++ bindings, etc) but I don't want to make these
> > >> changes until 1.3 is shipped as it would destabilise the code.
> > >> Mark
> > >>
> > >> > >
> > >> > > Hi Folks,
> > >> > >
> > >> > > the 1.3 release has not been declared.
> > >> > > What are the latest schedules ?
> > >> > > Are we waiting on any bugs to be fixed?
> > >> >
> > >> > linux user guide is obsolete. Need to update it. I'm going to fix
it
> > >> > tomorrow earliest
> > >> >
> > >> > thanks
> > >> > damitha
> > >> > >
> > >> > >
> > >> > >
> > >> > > John Hawkins
> > >> > >
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> > > _______________________________
> > > Do you Yahoo!?
> > > Declare Yourself - Register online to vote today!
> > > http://vote.yahoo.com
> > >
> > >
> >
> >
> >
>
>
>
>
> ---------------------------------
> Do you Yahoo!?
> vote.yahoo.com - Register online to vote today!
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com