Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@continuum.apache.org
Received-SPF: pass (nike.apache.org: domain of wsmoak@gmail.com designates
 209.85.221.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type:content-transfer-encoding;
        b=uXyHSym0gGM6L4O3L7+av8Ua/ciBTd27rcN6/1AfQ7L1KPl+yithrLYvjYg3qYP7r9
         V5/yfXy0oDS4ZyP7I+98I9H6AkqIych03JoOzbpdS6a4xWKD3+/23lHOl/IQx0wnRQu2
         JU/Kmu/IUt50e+9fx64dJp/4t2NifRPDHh4O0=
MIME-Version: 1.0
In-Reply-To: <0B4BED0C-0418-4B85-8891-9F99C138DD56@apache.org>
References: <0B4BED0C-0418-4B85-8891-9F99C138DD56@apache.org>
From: Wendy Smoak <wsmoak@gmail.com>
Date: Thu, 25 Jun 2009 07:57:58 -0700
Message-ID: <adba96190906250757k7135fe9ay33199745304dd106@mail.gmail.com>
Subject: Re: separating the builder code from the UI
To: dev@continuum.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I think Emmanuel just beat me to raising the topic of getting
(re-)started on this. :)

The diagrams from Brett's mail are here:
http://continuum.apache.org/ref/1.4.0-SNAPSHOT/architecture.html
(and the source files are available if anyone wants to edit, but they
are in OmniGraffle right now, which is not free.)

Rather than deciding up front that this will be Continuum 2.0, how
about a code-named branch?

-- 
Wendy

On Thu, Apr 10, 2008 at 11:48 PM, Brett Porter<brett@apache.org> 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
> [2] http://people.apache.org/~brett/continuum-proposal/continuum-new.png
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>