gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Generator vs Serializer
Date Mon, 29 Mar 2004 17:34:44 GMT
Sam Ruby wrote:

> Adam R. B. Jack wrote:
>  >
>  > We have gump.document.text, and we could create gump.document.html
>  > that use cheetah to write it.
> 
> Stefano Mazzocchi wrote:
> 
>>
>> +1 in removal of forrest and go plain XHTML + CSS. But please, let's 
>> use a velocity-like approach, not a DOM like approach!
> 
> 
> I may be reading too much into Stefano's words, but if so, the following 
> is how I see things.
> 
> At the moment, gump.document.* take a complete set of knowledge and 
> produce a set of artifacts.  The best analogy to Cocoon for this would 
> be a serializer which terminates a pipeline.
> 
> 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.  The best analogy to 
> Cocoon for this would be a generator which is at the beginning of a 
> pipeline.  Classic gump is closer to this model... after a brief 
> generation phase, the execution of the resulting script triggers 
> actions, the output of which is intermixed with some static and some 
> generated output.
> 
> 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.
> 
> Producing output as the information becomes available can also 
> dramatically reduce working set sizes.

Don't have much time to read email this week so, but I want to kick this 
is before things start changing.

Sam is correct about forrest being one massive serializer and gump one 
massive generator. The try/fail cycle is way too slow.

This is the usual criticism to forrest.

The usual thing that people miss is that forrest is supposed to be run 
"LIVE", that means "dynamic", that means "as a servlet" during 
development that is, when try/fail cycle needs to be fast. And it can be 
run in batch mode after that (it is able to do deltas and regenerate 
only the parts of the site that has changed).

My first proposal was to run forrest dynamic for gump. This means that 
you don't have to change anything in the code right now *AND* you get 
immediate changes as soon as they are written on disk.

Also, given that we proxypass thru mod_cache it anyway, you don't have 
any performance drawback.

As I said, I'm not against XHTML+CSS, but just worth considering as an 
alternative, also because, having it dynamic allows us to do more 
interesting things later on.

-- 
Stefano.


Mime
View raw message