axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sanjiva Weerawarana" <>
Subject Re: Work items for the next Release
Date Wed, 24 Mar 2004 07:33:59 GMT
I'm +1 for separating the publicly visible interface .h files
into a separate directory and also +1 for using Log4C .. no
need to invent unnecessarily!

My objective for this release is basically to capture what has
been done since the 1.0 release .. which was now nearly 3 months
ago! So I would recommend deferring the aggressive changes until
after this release - target them for 1.2 instead.

Who knows, at the rate Axis/Java does releases we may be at
1.3 before they ship 1.2 ;-). We MUST at least meet Axis/Java
in terms of quality and reliability however!


----- Original Message -----
From: "Lilantha Darshana" <>
To: "'Apache AXIS C Developers List'" <>
Sent: Monday, March 22, 2004 1:30 PM
Subject: RE: Work items for the next Release

> Damitha,
> >>>1).Source Restructuring
> >>>- Include files should be restructured in the CVS folder hiarachy to
> >>>include files that goes with binary distribution  seperately. Then CVS
> >>>folder /c/include will contain only the include files that goes with
> >>> binary
> >>>distribution and all  other include files are moved to the respective
> >> /c/src
> >>>folder.
> >>>
> >> Let all the header files stay in their respective folders with their
> >> files. When the library is build the build scripts (Makefile etc.) will
> >> take
> >>
> >> care of copying only the required header files to the c/include folder.
> >> So that binary distribution (tar ball) will contain the library with
> >> the required header file in the c/include.
> >
> >What I feel is that we let all the header files except files needed for
> >binary be in their source folders. We keep header files needed for binary
> >in the $AXISCPP_HOME/c/include. In that way from the beginng we
> >can cleary identify files which acts as interface to axis c++.
> >I don't see any gain by adding files to $AXISCPP_HOME/c/include only in
> >release time.
> There are few reasons for this suggestion:
> 1. Portability: The interpretation of the -I command option can differ
> from one system to another. Besides, it is not covered by the Standard.
> example,
> the directive #include "dir/file.h" in conjunction with -I.. would cause
> most
> preprocessors in a Unix-like environment to search for file.h in ../dir
> under
> VMS file.h is only searched for in the subdirectory dir in the current
> working
> directory. If you have your .h file with .cpp then "file.h" just look for
> the same folder and <file.h> will look for the folder specified by -I.
> And that allows us to avoid syntaxes like #include "dir/file.h".
> 2. Consistency: it's not consistence and difficult to find as project get
> larger
> If you keep some of the header files with respective .cpp file and others
> separately.
> 3. Binary is only available when you build the code, so do the header
> for the
> binary, if the build script copies them to the include folder.
> >>>
> >>>2) Writing critical failures to error logs.
> >>>
> >> I would vote for Log4c so that you can direct your output anywhere you
> >> want
> >> and
> >> only configured logs will be captured.
> >
> >Axis C++ already have a very simple log mechanism in which only
> >logs can be captured. I think that serves the purpose for the time being.
> >It's good if we can make a mechanism so that user can select and plug the
> >log mechanism he wants.
> >
> Why this suggestion is for:
> 1. As the project get larger it's cumbersome to trace problems in a real
> deployed
>  environment. So having an industry standard logging framework in place
> things easy.
> 2. Integrating such a logging framework at this time reduce the complexity
> because the
> code is not that complex hence the changes are minimal. Doing this later
> the code get
> complex has lot more price to pay.
> Pluggable logging framework is a good idea though.
> >> further I would vote for adding a JCA - resource connector to
> >> access AXIS C++ -- so that lots of today's enterprise deployments can
> >> take advantage of it when trying to access legacy codes/libs.
> >
> >I think if we could port Axis c++ to run with tomcat using JNI(I think
> >were working on this), then it is easy to add a resource connector.
> >
> right that's the minimum. Although, It seems like there is a restrictions
> on multi-processing requirements in the code base which Globes is looking
> for.
> I have suggested some design guide lines to achieve both requirements to
> Susantha
> that we need discussing further. Susantha, can you pls discuss this when
> meet
> with others. I need this one to be finished by now because we have spend
> beating around the bush. And there lots of potential clients looking for
> that.
> >But since axisc++ has been improved a lot after its first release we feel
> >that there need a new release immediately. So we need to consider whether
> >we could add this feature in the short time.
> >However I vote this feature for release 1.2 which also should come
> >very soon
> I'm not suggesting to add these changes to rel 1.1 but we can plan to have
> it
> by rel 1.2.
> regards
> -Lilantha

View raw message