continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Thakur <>
Subject Re: separating the builder code from the UI
Date Mon, 14 Apr 2008 04:33:32 GMT

+1 on the new branch.

I don't have comments per se, except that IMHO it appears that we should 
be considering reusing or implementing a Workflow engine as a part of 
the Builder refactoring. So, I will just lurk and watch the branch to 
see how this shapes up :-)


Brett Porter wrote:
> 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]
> [2]
> --
> Brett Porter

View raw message