An alternate approach would be to completely flip this. Have the equivalent logic drive the acquisition of certain pieces of information, which can be processed as it is being received.
Whilst most of the forrest documenter generates pages for single entities (for workspace/module/project/work) there are a significant number of statistics/xref pages that rely on all information being available. As such we'll need at least two phases.
"classic" gump handles such statistics pages separately too.
I'm not much into abstract architectural discussion. I tend to focus on tangible and measurable quanties that matter to real people. In this case, it is clear that Gump is expected to run for a long period of time, and I view not having ANY output until EVERYTHING is done as something less than ideal.
The use case of having 'personal Gumps' (not just relying upon the remote servers) has not been greatly exercised. [In the main 'cos I don't have the resources to run it locally]. We are moving more and more towards that usage though, so I could see how this could start to become important to folks.
I actually think there is considerable value in being able to view live results in the mult-hour run too, but it is fair to observe that classic gump "grew" in the other direction - being primarily used for my own personal builds which I ran multiple times a day, and an occasional complete resysnc, which I did every couple of weeks.
For us to get to the point where others are interested in personal gumps, we need to make it easier to build profiles which use repositories for components that an individual is not interested in rebuilding for themselves.
- Sam Ruby
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
