Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@continuum.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <0B4BED0C-0418-4B85-8891-9F99C138DD56@apache.org>
From: Brett Porter <brett@apache.org>
To: dev@continuum.apache.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: separating the builder code from the UI
Date: Fri, 11 Apr 2008 16:48:18 +1000

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
brett@apache.org
http://blogs.exist.com/bporter/