On 2/15/07, Andrew Borley <[EMAIL PROTECTED]> wrote:
On 2/15/07, Pete Robbins <[EMAIL PROTECTED]> wrote:
> 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.
>
> If we want a sample to demonstate using ws bindings then it should be a
> different sample, not just a separate client to the same samples: I don't
> want the <binding.ws > element in my basic sample scdl because I would not
> be able to run the basic CppCalculator without a ws binding extension. It
> would be good to show a ws binding sample re-using the components from the
> base sample though.
+1 I think separating out the technologies we're demonstrating with
each sample is a good idea.
> I'll start a thread for the M3 release content. It would be nice to have a
> matrix showing which samples require which extensions and on which platforms
> each extension is available (e.g. ws will not be available on Mac and PHP
> may not be available on Windows).
Agreed - I had the same idea, so I started putting this matrix
together in the samples HTML doc. I should be committing it later
today.
Cheers
Andrew
OK, it's committed - check out the Sample Dependencies table in
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/GettingStarted.html
It's a big table (I've split binding extension dependencies into their
service & reference pieces and also specified which container each
sample runs under - Axis2C simple HTTP server or HTTPD) - do people
think it helps? Could it be simplified in some way?
Cheers
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
