Hi,
I've been thinking ahead a bit about a potential design change I'd
like to make. At the moment, at a very coarse level, we have the
"Core" which does just about everything :), which is comprised of a
few modules, and the webapp/xmlrpc sitting on top of that. It looks
something like [1]. It is pretty well separated from the UI, but the
parts of the core are not well separated and hard to test, and the
store/model is pervasive through everything.
I would like to propose factoring out the bit that does the building,
something like [2].
This is not a totally radical change, though it will change the
workflow a bit such that:
* the builder has no database interactions. So it will be on the
return events that contain results that get persisted in the database
* notification will be based on the return events, not part of the
build logic
Clearly demarcating where the database is used is a Good Thing I feel,
and it then becomes a way to store and visualise results.
There are a couple of potential things that will later be possible
with this architecture:
- the requests could be made over REST and the events sent back over a
JMS Q similar to GBuild - allowing us to move the builder to an
entirely different server, and to have multiple builders. If each has
a given set of installations/environment profiles we can then
aggregate results for different platforms
- you could run Continuum with just the bottom layer for a really
simplified system. The only change we'd make here is that you'd hook
up the notifiers and other event responses directly instead of the Q
I'd like to attempt this on a branch, making the minimal amount of
change possible to see how it works. What do others think about this
approach?
Cheers,
Brett
[1] http://people.apache.org/~brett/continuum-proposal/continuum-now.png
[2] http://people.apache.org/~brett/continuum-proposal/continuum-new.png
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
