On Jul 1, 2006, at 2:42 AM, Jeremy Boynes wrote:
Jean-Sebastien Delfino wrote:
- Modularity, building our runtime in a more modular way, with more
but
simpler modules, clean SPI modules with only interfaces, and
decoupling the
core and the Java component implementation type / container.
- Simpler SPIs, covering all aspects of the cycle (development, build,
deployment + install, runtime, admin etc.)
There's several things here conflated together - I propose we tackle
them separately.
If you define runtime as a running SCA environment, I think we have a
good start on a modular approach. There are bound to be tweaks but I
think we are going in the right direction.
We have a basic core with a well-defined SPI into which we can add
extensions without needing any change to the core. We also have ways
in which extensions can co-operate, providing new extension points
themselves into which other things can plug. spi and core2 combined
are about 12000 lines of code and the binary is just over 300K in size
- this is not very big really.
I believe a good portion of that 300K is related to the Geronimo
WorkManager dependencies. Since WorkManager can be implemented as a
thin facade over the JDK 5 concurrency libraries, we should look at
implementing a simple one and eliminating the dependencies. Once we
do that, I think we will only need StAX, which is slated to become
part of the JDK anyway.
Having said that, I agree that we can restructure the SPI module to
make things a little clearer. I think some of the confusion now comes
because it contains both runtime and deployment interfaces. We agreed
a long time ago that we wanted the runtime to be self-contained and
independent of the deployment mechanism used. Bearing that in mind, we
should be able to separate the runtime part of the SPI from the
deployment part.
Taking a quick swag at the top-level packages in the SPI I would
propose we create two new ones, deployment and runtime, and move
things around as follows:
runtime:
bootstrap, component, event, host, monitor, policy, services, wire
deployment:
annotation, builder, deployer, loader, model
What does "annotation" do? On a related note, I think we also have a
POJO extension model for things like annotation processors. I don't
think this can be easily factored into an SPI below core since it
will drag in a whole bunch of things (either in the basic SPI package
or a special "POJO" SPI package). Any ideas would be
great...otherwise we may just say that type of extension is a "low-
level" one done off core.
Assuming this works and all dependencies point from deployment to
runtime we could then split the SPI module into two. I'd like to
re-evaluate before doing that though as I think a typical usage would
always have both runtime and deployment code and would typically
always need both modules.
I don't see separating these into two projects is worth the added
complexity. As long as we have a clear packaging structure, IMO it is
much easier to deal with one extension jar.
Making people deal with two things just
seems like unneeded complexity.
Finally, I think we need to be clear about what is an SPI and what is
an API. To me, an SPI is something used by an system to expand its
functionality, it's a view from the inside looking out; an API is used
by something else to manipulate a system, it's a view from the outside
looking in.
With that in mind I think some of the "SPIs" you mention above are
really APIs. Things like deployment, install, admin (and I'd add
management, monitoring) are interfaces the runtime would provide to
allow outside entities to manipulate it.
This is a god point. I think it also entails a different design
approach. For example, an SPI is intended for experienced, systems-
level programmers and therefore can sacrifice a bit of complexity for
power and flexibility.
I'd propose that this may be a better way to slice up the current spi
module. For example, we could consider splitting out the bootstrap and
deployer packages into a new "api" module. The intention would be to
provide interfaces used by external actors without exposing them to
the mechanisms used to extend the runtime.
--
Jeremy
---------------------------------------------------------------------
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]
