gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Re: [RT] Generator vs Serializer
Date Sun, 28 Mar 2004 18:09:02 GMT
> At the moment, gump.document.* take a complete set of knowledge and
> produce a set of artifacts.

Sounds accurate. [I am not familiar w/ Cocoon, so won't comment there.]

> 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.

I have no objection to this approach being implemented (see next e-mail).
The current design occured out of the developer (me) wanting to use Forrest
[to not get personally bogged down in HTML presentation], and not being
familiar with the Forrest/Cocoon webapp approach. If I'd known then what I'd
known now, I may well have chosen that approach.

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.

> 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.

Given a personal (perhaps debug) run, I can imagine somebody wanting to
monitor success as it goes. No point allowing an N hour test build to
continue if a key component fails early. Right now that is logged, and one
has to read the logs @ debug level to know.

I've thought about scripts and/or GUIs performing the various builds, and I
like the idea of a listener interface for state, and/or perhaps even a
listener interface for various stages (e.g. the trigger you state).
Personally, I'd like the context information to be stored and then presented
to the listener/trigger, so it is available for later phases & isn't lost.

> Producing output as the information becomes available can also
> dramatically reduce working set sizes.

FWIIW: In hindsight (having fixed a bug) .... there is insignificantly
little involved in storing the results tree in memory (a few
states/annotations/file references) compared to the metadata, and the pages
themselves. The 'big leak' was that the document objects (with DOM trees)
were not being freed up, despite the document variable being re-used.
Unlinking trees helped Python play nice, and this is no longer a significant



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message