On 09/02/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 2/9/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
> >
> > On 1/30/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > > On 1/30/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> > > >
> > > > [snip]
> > > > Simon Nash wrote:
> > > > > A repackaging into a kernel and language extensions as
suggested
> by
> > > > > Pete, Ignacio, and Jeremy seems like a good direction. We'll
> still
> > > > > have to find a name for the (native, C++, scripting, ???)
kernel,
> > > > > though. And we'll have to decide what kind of distribution
> bundling
> > > > > is helpful for our users. Jeremy's suggestion of combining
> related
> > > > > pieces from the "Java" and "C++" worlds seems like a good
> approach.
> > > > >
> > > > > I am not sure why we would put the cpp language extension
into the
> > > > > kernel, as suggested by Pete. Is this because it is needed
by all
> > > > > other extensions that support scripting languages?
> > > > >
> > > > > Simon
> > > > >
> > > >
> > > > After having thought about various other code names, I'm
starting to
> > > > like "native".
> > > >
> > > > I am +1 with separating a kernel from the extensions. The CPP
source
> > > > tree and build structure already have this separation anyway.
The
> > kernel
> > > > does not depend on the C++ component type support extension so I
> don't
> > > > think that it should include that extension.
> > > >
> > > > I also like Jeremy's suggestion of combining the current
java/ruby
> and
> > > > cpp/ruby into a Ruby top level module containing the code to
support
> > > > both Jruby/Java and the Ruby native interpreter and a shared
set of
> > > > samples. I think that the same idea will work well for other
> Scripting
> > > > component types (Python, Javascript etc.) and will help us
ensure
> > > > consistency across runtimes.
> > > >
> > > > I propose to go even further and generalize this idea to
bindings
> (WS
> > > > binding, REST binding, an AMQP/Qpid binding may be a good
candidate
> > too)
> > > > and other component types as well.
> > > >
> > > > I would like to stage some of these changes as they will
generate
> > > > significant work to adjust all the build files etc. I'd
suggest to
> > start
> > > > changing the terminology (core to kernel, C++ to native) and
see how
> > we
> > > > can share some samples, but attack the refactoring of the source
> trees
> > > > and the build system later, after the C++/native M3 release.
> > > >
> > > > Thoughts?
> > > >
> > > > --
> > > > Jean-Sebastien
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > > All of this refactoring sounds interesting and many systems
> distribute
> > a
> > > core/kernel and then optionally allow you to download
extensions, PHP
> > for
> > > example. I should say that in the PHP case poplar extensions find
> their
> > way
> > > into the kernel/core over time once they have proved their worth
> because
> > > people don't particularly like downloading extensions.
> > >
> > > As Jean-Sebastien pointed out this separation already exists in
the
> make
> > > system so the user can choose precisely which bits to build
once the
> > source
> > > distro has been downloaded. In the case of the binary distro I
think
> the
> > > case will be that the system only picks up those extensions
that you
> > > reference in SCDL so that fact that you have installed all of
them is
> > not an
> > > issue given the number of extensions we have now. I would
therefore
> > suggest
> > > that the extra complexity of delivering physically separate
tars for
> > > extensions and kernel is not required for M3 particularly because
> > Jeremy's
> > > ideas are interesting and may lead to rehashing the details of how
> this
> > is
> > > done for M4 anyhow.
> > >
> > > Simon
> > >
> >
> > I think I'm leaning towards this strategy too now - keep a single
> > binary downloadable package - as Simon says "the system only
picks up
> > those extensions that you reference in SCDL so that fact that you
have
> > installed all of them is not an issue".
> >
> > I do think we still need a name change, and "native" seems to be the
> > favourite. I'm happy with this - what do others think?
> >
> > The only issue is with our samples - most of them require more than
> > one extension (e.g. the PythonCalculator shows the use of both the
> > Python and WS binding extensions) - maybe we should split some of
them
> > up a bit more. With clear docs that explain what each sample
requires
> > this should be OK.
> >
> > So my proposal now is that the C++ M3 release provides source and
> > binary "Tuscany SCA Native" packages for Windows, Linux and Mac OSX,
> > with only the extensions (and their respective samples) that can be
> > built on that OS available within the package (e.g. no Axis WS
binding
> > on Mac).
> >
> > This has gone round in circles a bit - apologies for that! What do
> people
> > think?
> >
> > Cheers
> > Andy
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > Andy
>
> Thanks for pulling us back to this.
>
> +1 to "Tuscany SCA Native" & to source and binary packages for
Windows,
> Linux and Mac OSX
>
> Re. samples. Good point! We have mostly implementation specific
samples
> with
> a few higher level samples sprinkled in. (PHPCalculator is perhaps a
> little
> unusual in that it includes C++ components because, at this point
in time,
> it has to).
>
> AlertAggregator
> CppBigBank
> CppCalculator
> HttpdBigBank
> PHPCalculator
> PythonCalculator
> PythonWeatherForecast
> RestCalculator
> RestCustomer
> RestYahoo
> RubyBigBank
> RubyCalculator
>
> There is a general pattern that has a sample direcotry organized as:
>
> xyz
> sample.xyz
> sample.xyz.composite
> sample.xyz.client
> sample.xyz.wsclient
> sample.xyz.app.composite
>
> The source structure for the sample is reflected when it's
deployed. This
> seems to make it difficult to mix and match the components of
samples, or
> indeed provide differing bindings in different situations or on
different
> platforms.
>
> The first options that come to mind (i'm sure there are lots more):
>
> 1/ Allow components to be resused across samples. I don't know how
to do
> this in as much as the runtime seems to recurse down the application
> directoy looking for composites. Could be a deployment step to copy in
> composites as required.
>
> 2/ Can we use the deployment step to choose the application level
> composite
> that's appropriate. I.e rather than having LocalCppCalculator and
> WSCppCalculator have
>
> CppCalculator
> ...
> samples.calcualtor.local.app.composite
> samples.calculator.ws.app.composite
>
> And allow both or either verisions to be deployed if required.
>
> 3/ Change the runtime to allow us to point to a specific application
> composite files. It's possible that it already does this but I just
don't
> know how.
>
> ...
>
> Simon
>
I think a reorganisation of the samples is required but I'm not sure
whether
this would be too much churn for the M3 release. I think there should
be at
lease one sample for each language extension that simply demonstrates
the
language binding. The xxxCalculator series seems to be the best (ans
easiest) choice.
For Cpp I have deleted the Axis2C client sample for cpp client and
will also
do this for the CppBigBank sample. We are not trying to demonstrate
how to
code Axis samples! SO.. now I can build the core/kernel tuscany_sca
and the
cpp extension tuscany_sca_cpp and be able to run the CppCalculator
sample.
That's all I need.
our build
