Re: [VOTE] Tuscany C++ sub-project name

[Andrew Borley <aj...@gmail.com>]

On 1/30/07, Simon Laws <si...@googlemail.com> wrote:
> On 1/30/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [VOTE] Tuscany C++ sub-project name

[Andrew Borley <aj...@gmail.com>]

On 2/15/07, Andrew Borley <aj...@gmail.com> wrote:
> On 2/15/07, Pete Robbins <ro...@googlemail.com> wrote:
> > On 09/02/07, Simon Laws <si...@googlemail.com> wrote:
> > >
> > > On 2/9/07, Andrew Borley <aj...@gmail.com> wrote:
> > > >
> > > > On 1/30/07, Simon Laws <si...@googlemail.com> wrote:
> > > > > On 1/30/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > > >
> > > > > > 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > > 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [VOTE] Tuscany C++ sub-project name

[Andrew Borley <aj...@gmail.com>]

On 2/16/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Andrew Borley wrote:
> > On 2/15/07, Pete Robbins <ro...@googlemail.com> wrote:
> >> On 09/02/07, Simon Laws <si...@googlemail.com> wrote:
> >> >
> >> > On 2/9/07, Andrew Borley <aj...@gmail.com> wrote:
> >> > >
> >> > > On 1/30/07, Simon Laws <si...@googlemail.com> wrote:
> >> > > > On 1/30/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> > > > >
> >> > > > > 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: tuscany-dev-unsubscribe@ws.apache.org
> >> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >> > >
> >> > > 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>

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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [VOTE] Tuscany C++ sub-project name

[Jean-Sebastien Delfino <js...@apache.org>]

Andrew Borley wrote:
> On 2/15/07, Pete Robbins <ro...@googlemail.com> wrote:
>> On 09/02/07, Simon Laws <si...@googlemail.com> wrote:
>> >
>> > On 2/9/07, Andrew Borley <aj...@gmail.com> wrote:
>> > >
>> > > On 1/30/07, Simon Laws <si...@googlemail.com> wrote:
>> > > > On 1/30/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
>> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > > > >
>> > > > > 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: tuscany-dev-unsubscribe@ws.apache.org
>> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>> > >
>> > > 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [VOTE] Tuscany C++ sub-project name

[Andrew Borley <aj...@gmail.com>]

On 2/15/07, Pete Robbins <ro...@googlemail.com> wrote:
> On 09/02/07, Simon Laws <si...@googlemail.com> wrote:
> >
> > On 2/9/07, Andrew Borley <aj...@gmail.com> wrote:
> > >
> > > On 1/30/07, Simon Laws <si...@googlemail.com> wrote:
> > > > On 1/30/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > > >
> > > > > 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: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > > 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

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: [VOTE] Tuscany C++ sub-project name

[Pete Robbins <ro...@googlemail.com>]

On 09/02/07, Simon Laws <si...@googlemail.com> wrote:
>
> On 2/9/07, Andrew Borley <aj...@gmail.com> wrote:
> >
> > On 1/30/07, Simon Laws <si...@googlemail.com> wrote:
> > > On 1/30/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > > >
> > > > 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > 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.

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).

Cheers,

-- 
Pete

Re: [VOTE] Tuscany C++ sub-project name

[Simon Laws <si...@googlemail.com>]

On 2/9/07, Andrew Borley <aj...@gmail.com> wrote:
>
> On 1/30/07, Simon Laws <si...@googlemail.com> wrote:
> > On 1/30/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > > 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> 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