axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lilantha Darshana <ldarsh...@edocs.com>
Subject RE: Work items for the next Release
Date Mon, 22 Mar 2004 07:30:50 GMT
Damitha,

>>>1).Source Restructuring
>>>- Include files should be restructured in the CVS folder hiarachy to keep
>>>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 .cpp
>> 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 only
>> the required header file in the c/include.
>
>What I feel is that we let all the header files except files needed for the
>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. For
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 but
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 files
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 configured
>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 make
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 as
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 you
>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 you
meet
with others. I need this one to be finished by now because we have spend lot

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


Mime
View raw message