continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Venisse" <>
Subject Re: separating the builder code from the UI
Date Fri, 11 Apr 2008 09:09:23 GMT
It's good to see we have a similar (the same) vision.

I'm not sure notifiers is at the good place but it is a detail.
I think we need to detail a bit more the architecture schema because this
simplified vision generate the code we have actually (one class for the core
==> DefaultContinuum, and one class for the store). If we want a good
architecture, and a good presentation page on the site for the community,
I'm pretty sure it would be good to detail the api/core and store blocks.


On Fri, Apr 11, 2008 at 8:48 AM, 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message