Here are a few thoughts and questions on our SPI story. I'd like to
start a discussion on these items and get your thoughts.
A. I think we should create different projects for the various types of
SPI we have, for example one project for the assembly model SPI, one
project for the interaction/invocation related SPI, one project for the
deployment SPI, one for the management SPI etc.
If these SPI go into a spec at some point this will allow us to publish
them and evolve them independently.
I also think that this allows to cut complexity, for example a
contributor only interested in management will not get the other SPIs.
More generally, somebody assembling/embedding a Tuscany runtime will be
in a better position to pick a subset of selected pieces.
Finally this shows a clear path to people who want to extend the
runtime, for example, if we put the java interface support in a
different project, the WSDL interface support in another one, then
somebody wanting to add ruby or javascript support will have a clear
template to follow.
B. I'd like to separate interfaces and implementation classes or helpers
in different projects. For example the assembly model interfaces would
go into one project, the Tuscany implementation of these interfaces in a
different one. In M1 we have interfaces+implementation classes but they
are in the same project, in the sandbox there's no interfaces anymore
for this, can you guys tell me what motivated that change?
Separate interfaces and implementation classes will allow us to swap
different implementations (e.g. using different databindings, or
integrated with tooling for example). It will also allow model
extensions to not depend on Tuscany implementations classes (the
extensions will only implement interfaces instead of extending
implementation classes).
C. I would like to change the project folder structure a little and
introduce a plugins/ directory where contributors could drop their
extension projects/modules. It is not clear to me anymore that we need
different bindings/ and containers/ folders. I'm thinking more and more
that the programming model for component implementation extensions and
binding extensions should be the same. Some plugins will not be
implementation or binding specific, for example it should be possible to
contribute a plugin that provides support for a new interface definition
language. Also these plugins will have to contribute multiple extensions
covering codegen/development, model, validation, deployment, install,
invocation, management etc.
Any thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
