gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Jack" <aj...@mric.coop>
Subject Gump3 inter-component orchestration/communications
Date Sun, 10 Apr 2005 23:19:52 GMT

Why are CvsUpdater, SvnUpdater pre-process plug-ins, not 'process' visitors?
Clearly (as of now) it make little difference, I'm just trying to
understand.

I'm not sure I'm comfortable with the three pre-process/process/post-process
walks. Is this a Gump2 hold over that we want in Gump3? 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?

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. We ought
update a DB and (say) notify of a failure (e.g. e-mail or RSS) ASAP [i.e. at
t he time of the processing], to give communities the most opportunity to
solve things before the next Gump run.

I like how Gump3 is simple, and fires events out to plugins (letting them
decide if they wish to process them, not centralizing this logic) however I
think that'll put a higher burden onto inter-component orchestration and
communications. I think using the model object as a "message board" by
writing attributes is the right Pythonic way to solve the latter. It is the
former that worries me.

I don't have a solution here, I'm just asking questions...

regards,

Adam


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


Mime
View raw message