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.
This sounds good, especially when we deal with high level building
blocks like management. One thing I think we need to be careful of
though is breaking it down too far so that we force users to
understand several different modules just to do something simple. I
think we can address that with the right package structure in each
module.
If these SPI go into a spec at some point this will allow us to publish
them and evolve them independently.
Agreed. We are actually leading the spec here which gives us a chance
to influence the direction it is taking. However, when the spec
actually adopts something the classes will move from the o.a.t
namespace to the org.osoa one which will impact users and
implementations. We can handle those changes for both separate modules
and individual packages within a module.
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.
Cutting complexity is good and we can help with that by making sure
that things that naturally go together are bundled together. For
example, someone writing an extension should not need to dig through
several modules to figure out what they need to do.
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.
I'm not sure what you mean here. This sounds like two implementations
of a "pluggable interface type" SPI - one for Java interfaces, one for
WSDL ones - which I think would be a good way to break this down.
B. I'd like to separate interfaces and implementation classes or helpers
in different projects.
Wholeheartedly agree on the separation between interface and
implementation. In M1 we did this but had both inside the same module
which was confusing; one of the things we did in the sandbox was to
move the interfaces into spi and leave the implementation in core.
I think helpers can go either way. If they are useful (but optional)
to any implementation of the interface, then we can reduce the
complexity by including them with the SPI. An example of this would be
the extension base classes that contain functionality to support an
implementation but which (in general) don't implement the interface
contracts. On the other hand, classes that support a specific
implementation should just be part of it (directly or in the form of a
library).
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?
Simplicity really. The model objects are really just data holders (set
and get methods only) and don't contain significant implementation.
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.
I think we're heading the same way here. To me, containers and
bindings were just a couple of types of plugin - two types out of
many, there were also system services, tools and so on. Moving the
plugins into a location separate from the core makes sense.
On a closing note, I'd suggest there a couple of concrete things we
can look at:
1) Look at the spi package and see if we can identify things that
stand alone and could be broken out. For example, I've been thinking
we might bundle deployer, model, loader and builder together in a
deployment package.
2) Look at our deployment story and see how we can package plugins. I
think a couple of people have suggested that OSGi bundling may work
for us. Having a management API for deploying new modules would be
good too.
3) Keep looking at the extension interfaces and see how they fit with
actual extensions. You mentioned javascript and ruby containers and I
think Ant was looking at how rhino could work with the sandbox code.
Jim, Dan and Jervis are working on getting Celtix to work with it; it
would be interesting to see how Axis2 fitted in.
4) Let's look at some of the newer more complex areas such as
Raymond's data mapping, Ant's interface representation, or the async
stuff Scott mentioned and see if the SPIs we have work or if they need
to be tweaked.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
