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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
