On 2/16/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Andrew Borley 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.
>> our build
+1
>> 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.
>
+1 for removing the WS binding dependency from the C++ bigbank sample.
However, I'd prefer if we kept the WS and REST bindings in the other
samples (Ruby, Python, PHP etc.). I think that SCA is most useful when
you want to integrate multiple things (scripts, legacy code, Web and
REST services), so isolating the samples (e.g a Ruby or a Python sample
with no bindings) to achieve more modularity will make our build happy
but will make the samples much less interesting.
>> 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.
Looks good, I think it would be nice to have 2 different tables:
- the features illustrated by each sample, what language, what binding etc.
- the dependencies Apache HTTPD, Curl, Axis2C, the various script
interpreters
>
> Cheers
> Andrew
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
Hi All,
This vote never got properly completed, so I shall close it based on a
lazy consensus.
Tuscany SCA for C++ will henceforth be named Tuscany SCA Native.
Please comment if there are any issues with this.
Cheers
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
