Pete Robbins wrote:
On 28/11/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Pete Robbins wrote:
> I'm in the process of porting Tuscany C++ to Mac OSX continuing the
work
> that Oisin started. Axis2C does not have an OSX port yet (Oisin's
> supplied
> patch has not been applied) and I've been having a few problems
building
> their code which are probably simple to solve but I want to focus on
> getting
> the Tuscany core ported.
>
> I would like to remove the dependency on Axis2C and make it optional.
>
> For SDO this would be achieved simply by not building the sdo_axiom
> utility
> library.
>
> For SCA it is more complex. FIrst of all we would not build the
> current WS
> binding extensions. Some of the samples would have to be changed so we
do
> not build the wsclients which are Axis2C specific. I think we may also
> have
> to provide a dummy ws binding in place of the Axis2C versions.
>
> For Linux/Mac we can have a --with-axis2c option on the configure
script.
> For Windows I changed the build.bat script to optionally build
> extensions,
> e.g. if PYTHON_HOME is not set then the python extension is not built,
> so we
> could optionally build with Axis if AXIS2C_HOME is set. It may be
> better to
> code optional parameters onto the build.bat script to control the
> build to
> be in line with the Linux build but for now using the environment
> variables
> is OK.
>
> Any thoughts?
>
> Cheers,
>
Pete,
This sounds good to me. A few more thoughts:
- +1 for just detecting the AXIS2C_HOME environment variable on Windows,
this is more convenient if you build from the IDE as well.
- On Linux we already have --enable-wsbinding=yes/no config option. I
think we could just change the default to "no", instead of introducing a
dummy ws binding and another --with-axis2c config option.
- Most of our samples depend on WS on both the client and server side,
so turning them into variable geometry samples with an optional WS part
sounds a bit complicated :) Could we just use a
--enable-wsbinding=yes/no option to enable/disable the samples that
require the WS binding? I realize that this will disable most of our
current samples but this situation is evolving... We already have a
RestCalculator sample that works without the WS binding, I'm about to
add another REST sample, Andy is adding a new Python sample, and I'll
probably add next a sample that reuses an existing C++ library, which
won't use WS either. Soon we'll have enough non-WS samples to illustrate
the SCA programming model... and disabling the WS samples won't be a
problem.
What do you think?
--
Jean-Sebastien
binding.ws is part of the core assembly model so we should have at least
something that registers to handle those scdl elements. This is my
thinking
for a dummy/default ws binding extension. When I took out the existing
Axis2C ws extension our simple C++ Calculator sample with C++ client
fails
because the .composite declares a <binding.ws> although this is only
used in
the ws client case.
So I think --enable-wsbinding should always be true and in fact the
option
would be redundant. Control over who provides the ws binding extension
can
be with a different switch --with-axis/--with-petes-super-ws-package or
whatever.
It makes sense to me for the CppCalcualtor sample to conditionally
build the
wsclient rather than have a separate sample with/without ws.
Cheers,
This poses interesting questions :)
Should we be able to build a runtime with a subset of the "core"
bindings and component implementation types? I would say yes. For
example, you may want to build scaled down versions of the runtime for
use in a distributed environment, in parts of your system where you
don't need Web services support, or no C++ support, etc.
What did you mean by a dummy/default WS binding? Would it be functional
like the Axis2C based one? If yes, how would you want to implement it?
If no, what would be the purpose of that binding?
Conditionally build the wsclient part of the samples is not going to be
sufficient. As you said the sample .composite files also depend on the
WS binding, so I guess we'd have to strip the binding.ws elements out of
the sample composite files when the WS binding is not enabled... other
wise it's going to be pretty confusing to have them there but no Web
Services created for them... Any thoughts on how to do this simply?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
