[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]
