Mailing-List: contact general-help@gump.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Gump code and data" <general@gump.apache.org>
Message-ID: <0eb301c53f9f$1d727f00$6501a8c0@sybase.com>
From: "Adam R. B. Jack" <ajack@apache.org>
To: "Gump code and data" <general@gump.apache.org>
References: <BE81B7AD.25CE5%mail@leosimons.com>
Subject: Re: Gump3 inter-component orchestration/communications
Date: Tue, 12 Apr 2005 14:35:05 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> > I'm not wanting us
> > to design a generic mechanism, just solve our problem, but is the
approach
> > the right one? Why are these three walks better than (say) putting
> > Updates/Builders/Databasers(DynaGumper) in sequence inside one mutlicast
> > plugin?
>
> Do you think we could do without multiple stages completely?

I think it just comes down to order. The "walker logic" I've preferred most
is the one that iterates through projects, visiting modules (and
repositiories and workspaces, etc.) on demand (for those projects) and
visiting each plug-in in sequence. A sequence of (1) start time stamp (2)
build (3) end time stamp (4) DB update (5) notify -- seems fine w/o need for
pre or post processing. So, I guess (as of my view right now) "yes, maybe".

That said, I've not thought throguh some of the more "intelligent"
behaviours we'd like, such as aggregations (so we don't spam folks w/
e-mails or RSS/Atom feeds, etc.)

> > One side effect of the current approach is that (during a long slow
build)
> > we'll only update the database at the end of the run, after all modules
have
> > been updated and all projects have been built. This was something we
found
> > unpleasant w/ Gump2, 'cos folks want more instant gratification.
>
> Really? I've always found it really annoying to want to debug something
and
> then seeing that a build is "in progress" meaning part of that tree is
from
> the run before and part of it is new. Very confusing...

Yup, agreed, but that is something I hope we can fix with the Gump3
separation of run from presentation, via DB. Given that we'll uniquely
identify DB updates per run, they ought be able to be made any time, and the
presentation still show "last complete run" w/o confusion.

    ----

This all said, I'm in no hurry to redesign things and remove the three
phase, I was just wondering. Time will tell.

BTW: One last thought .... property bloat leading to memory bloat. I've
found with Python (for Gump2) that object/property bloat can really clog
things up. Sure, a lot of it was the DOM tree (and those are being pruned)
but I do think we'll hit this later, with full runs. I'm not saying we ought
think about this now (I just have scars from months of fighting performance,
so can't forget) but we might want some sort of Reaper plug-in that keeps us
lean. That'd need to run after all plug-ins for a project. Again, time will
tell...

regards


Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org