gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <>
Subject Re: [RT] Generator vs Serializer
Date Sun, 28 Mar 2004 19:32:29 GMT
Adam R. B. Jack wrote:
>>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:
For additional commands, e-mail:

View raw message