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
