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
Jeremy Boynes wrote:
What we're moving to on the "other side" is something like:
SCA Kernel
SCA XXX Distribution
SCA Maven Plugin for XXX
SCA Extension for XXX
It sounds like the C++ structure is evolving the same way with a
kernel, multiple distributions, extensions etc. In some ways I think
you have more infrastructure generally available with package managers
such as yum that allow users to easily install packages and their
dependencies. IMO that would allow you to get the advantages of modular
packaging without inconveniencing users (although you might need to
provide metadata for the different managers).
On the Java side we're moving to a model where users don't need to
manually install extensions - they can automatically be installed by
the runtime based on the SCDL content. For example, if we see
<impl.ruby> we'd automatically install the ruby extension where it was
needed. Could the "native" runtime do the same thing?
We're also distributing the samples separately so that users can pick
them up independently of the packages and vice versa. Samples in "non-
native" programming languages such as Ruby should run on both "native"
and Java runtimes - perhaps we should have one set?
Perhaps we should go even further and make the extensions top-level
modules. So (picking ruby as an example), instead of java/ruby and
cpp/ruby, have a single ruby module with java and cpp sub-modules. Then
the people working on ruby would be able to ensure consistency for
their users across both runtimes.
--
Jeremy
On Jan 26, 2007, at 2:23 AM, Andrew Borley wrote:
On 1/24/07, Oisin Hurley <[EMAIL PROTECTED]> wrote:
On 23 Jan 2007, at 10:55, Pete Robbins wrote:
> I was wondering whether we should package a Tuscany C++ kernel,
> which is
> the core runtime and cpp language extension, and have a separate
> package for
> scripting extensions ??
+1
--oh
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
OK, so we have a split vote here - some people preferring "Tuscany SCA
Native" and others preferring to split out the distributions into
something along the following lines:
"Tuscany SCA for C++" - contains kernel, C++ extension and C++ samples
"Tuscany SCA for Scripting" - contains Python, Ruby, PHP extensions
and samples, requires Tuscany C++
"Tuscany SCA for C++ Bindings" - contains WS (Axis2C), REST and SCA
binding extensions and samples, requires Tuscany C++
Alternatively, we could split these up even further, into a separate
package for each extension.
+ves for "Tuscany SCA Native": single downloadable package, no
languages named (avoids confusion), unified documentation.
-ves for "Tuscany SCA Native": requires lots of other packages to
build it (some of which aren't available, e.g. axis on Mac), includes
function that users may not need/want
+ves for separated packages: User downloads what they want to use or
what is available on their platform. Packages clearly say what is
inside them.
-ves for separated packages: More work to generate and test the
combinations of packages, possibility of packages getting out-of-sync
with each other (would need some versioning scheme?).
We could, of course, offer a single package containing everything as
well as the separated packages.
Thoughts, further votes, etc appreciated.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK [EMAIL PROTECTED]
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
