I think ideas like this are very interesting, I love this out-of-the-box type thinking separating Gump past from Gump future. With the Python codebase such things become much more possible. I say we handle issues with "monster dependencies" (such as with Ant) either by a flag
Not the same, but a different approach is that when Gump does it's module updates it checks for 'activity'. CVS (in quiet mode) only list updates, and is silent if nothing changed. As such, a flag is set as to wether the module (not project, somewhat crude). I document this right now (to try to display when something is stale) but it could be used as an optimization. Gump has mutliple code paths these days, and optimization switches, this sort of stuff is very doable. Note, with RSS the "nagged to death" issue isn't such a problem. Folk can use their RSS reader to tap into a workspace (a Stefan, or Gumpmeister), a module (e.g. Ant), or a project & they can override the 'update window' to hours/mins/days, whatever they want. Basically, with RSS output we can nag up the wazoo w/o being a pain. [I am just tweaking the RSS feed, a couple of presentation bug, I'll post here when ready to be viewed. I also want some help from Blogmeisters on if Gump ping topic serves, etc.] There is so much *good stuff* we can do with this start. We need more active coders in Gump, we (I) need to document what is there (the Python code is getting pretty manageable now), and we need to recruit.Gump is a social experiment that needs more close friends. Thoughts on how? regards, Adam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
