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/10/20 12:11:00 UTC
Process for renaming .h to .hpp [WAS Re: Fw: RE: Re: 1.3 release]
Hi Samisa,
I would prefer not to make one *massive* commit, renaming all the external
.h files, changing all the places where they are included and changing
wsdl2ws at the same time, since this is error prone and would require a
superhuman effort. Instead I would prefer to make the change incrementally
with small commits, making sure that the tests run all the time, never
breaking the product. So this is how I plan to do it...
1) Wait until 1.3 is shipped
2) Disable wsdl2ws from generating C artifacts (one line change)
3) Notify the mailing list of what I'm doing
4) Copy all the external .h files to .hpp files without removing C support
(so there are 2 identical copies committed in CVS)
5) Change all the includes throughout the product to include the .hpp
headers, committing incrementally
6) Change wsdl2ws to make the generated C++ artifacts include the .hpp
headers
7) Make the sure the .hpp headers are up to date by merging in any changes
that other committers have been making to the .h files
8) Replace the contents of the .h files with a suitable #error
9) Remove C support from the new .hpp files
10) Fix problems with the directory structure (client includes axis/server
headers, empty classes, etc)
11) A couple of weeks later remove the .h files completely
Mark
Mark Whitlock
IBM
----- Forwarded by Mark Whitlock/UK/IBM on 10/20/2004 10:11 AM -----
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
10/20/2004 02:44 <ax...@ws.apache.org>
AM cc
Subject
Please respond to Re: Fw: RE: Re: 1.3 release
"Apache AXIS C
Developers List"
Hi Mark,
Would you be changing C to C++ (including header changes) module by
module (e.g. one folder in
src at a time - engine, soap, xml etc.) and commit to CVS or would you do
all the changes and then
commit to the CVS at once?
Thanks,
Samisa...
--- Mark Whitlock <ma...@uk.ibm.com> wrote:
>
>
>
>
> 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 <ax...@ws.apache.org>
>
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 <fa...@opensource.lk> 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!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Re: Process for renaming .h to .hpp [WAS Re: Fw: RE: Re: 1.3 release]
Posted by John Hawkins <HA...@uk.ibm.com>.
+1 !
Good approach :-)
John Hawkins
Mark
Whitlock/UK/IBM@I
BMGB To
axis-c-dev@ws.apache.org
20/10/2004 11:11 cc
Subject
Please respond to Process for renaming .h to .hpp
"Apache AXIS C [WAS Re: Fw: RE: Re: 1.3 release]
Developers List"
Hi Samisa,
I would prefer not to make one *massive* commit, renaming all the external
.h files, changing all the places where they are included and changing
wsdl2ws at the same time, since this is error prone and would require a
superhuman effort. Instead I would prefer to make the change incrementally
with small commits, making sure that the tests run all the time, never
breaking the product. So this is how I plan to do it...
1) Wait until 1.3 is shipped
2) Disable wsdl2ws from generating C artifacts (one line change)
3) Notify the mailing list of what I'm doing
4) Copy all the external .h files to .hpp files without removing C support
(so there are 2 identical copies committed in CVS)
5) Change all the includes throughout the product to include the .hpp
headers, committing incrementally
6) Change wsdl2ws to make the generated C++ artifacts include the .hpp
headers
7) Make the sure the .hpp headers are up to date by merging in any changes
that other committers have been making to the .h files
8) Replace the contents of the .h files with a suitable #error
9) Remove C support from the new .hpp files
10) Fix problems with the directory structure (client includes axis/server
headers, empty classes, etc)
11) A couple of weeks later remove the .h files completely
Mark
Mark Whitlock
IBM
----- Forwarded by Mark Whitlock/UK/IBM on 10/20/2004 10:11 AM -----
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
10/20/2004 02:44 <ax...@ws.apache.org>
AM cc
Subject
Please respond to Re: Fw: RE: Re: 1.3 release
"Apache AXIS C
Developers List"
Hi Mark,
Would you be changing C to C++ (including header changes) module by
module (e.g. one folder in
src at a time - engine, soap, xml etc.) and commit to CVS or would you do
all the changes and then
commit to the CVS at once?
Thanks,
Samisa...
--- Mark Whitlock <ma...@uk.ibm.com> wrote:
>
>
>
>
> 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 <ax...@ws.apache.org>
>
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 <fa...@opensource.lk> 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!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
Re: Process for renaming .h to .hpp [WAS Re: Fw: RE: Re: 1.3 release]
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
+1 for the process.
Well planned :)
Samisa...
--- Mark Whitlock <ma...@uk.ibm.com> wrote:
>
>
>
>
> Hi Samisa,
> I would prefer not to make one *massive* commit, renaming all the external
> .h files, changing all the places where they are included and changing
> wsdl2ws at the same time, since this is error prone and would require a
> superhuman effort. Instead I would prefer to make the change incrementally
> with small commits, making sure that the tests run all the time, never
> breaking the product. So this is how I plan to do it...
>
> 1) Wait until 1.3 is shipped
> 2) Disable wsdl2ws from generating C artifacts (one line change)
> 3) Notify the mailing list of what I'm doing
> 4) Copy all the external .h files to .hpp files without removing C support
> (so there are 2 identical copies committed in CVS)
> 5) Change all the includes throughout the product to include the .hpp
> headers, committing incrementally
> 6) Change wsdl2ws to make the generated C++ artifacts include the .hpp
> headers
> 7) Make the sure the .hpp headers are up to date by merging in any changes
> that other committers have been making to the .h files
> 8) Replace the contents of the .h files with a suitable #error
> 9) Remove C support from the new .hpp files
> 10) Fix problems with the directory structure (client includes axis/server
> headers, empty classes, etc)
> 11) A couple of weeks later remove the .h files completely
>
> Mark
> Mark Whitlock
> IBM
>
> ----- Forwarded by Mark Whitlock/UK/IBM on 10/20/2004 10:11 AM -----
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com> To
> Apache AXIS C Developers List
> 10/20/2004 02:44 <ax...@ws.apache.org>
> AM cc
>
> Subject
> Please respond to Re: Fw: RE: Re: 1.3 release
> "Apache AXIS C
> Developers List"
>
>
>
>
>
>
>
>
>
>
> Hi Mark,
> Would you be changing C to C++ (including header changes) module by
> module (e.g. one folder in
> src at a time - engine, soap, xml etc.) and commit to CVS or would you do
> all the changes and then
> commit to the CVS at once?
>
> Thanks,
> Samisa...
>
> --- Mark Whitlock <ma...@uk.ibm.com> wrote:
>
> >
> >
> >
> >
> > 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 <ax...@ws.apache.org>
>
> >
> 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 <fa...@opensource.lk> 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
> > >>
> > >> > >
>
=== message truncated ===
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com