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.
Emmanuel On Fri, Apr 11, 2008 at 8:48 AM, Brett Porter <[EMAIL PROTECTED]> 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] > http://people.apache.org/~brett/continuum-proposal/continuum-now.png<http://people.apache.org/%7Ebrett/continuum-proposal/continuum-now.png> > [2] > http://people.apache.org/~brett/continuum-proposal/continuum-new.png<http://people.apache.org/%7Ebrett/continuum-proposal/continuum-new.png> > > -- > Brett Porter > [EMAIL PROTECTED] > http://blogs.exist.com/bporter/ > >
