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?