Re: Are navigation classes in for the same fate as screen classesin Turbine-3

[Jason van Zyl <jv...@zenplex.com>]

On 1/16/02 10:37 AM, "Gareth Coltman" <ga...@majorband.co.uk>
wrote:

> Hi,
> 
> Sorry about my previous post, it wasn't intended to go to the list, but it
> doesn't matter!
> 
> Anyway, Jason posted:
> 
>>>>>>> 
> No problem. Turbine 3 at the core will have no knowledge of a screen,
> navigation or layout but the model (the classic model) will still be a valid
> usage pattern. Scarab is currently using Turbine 3 along with screens,
> navigations and layouts. How you structure your view will be determined by
> the collection of valves used. Turbine will be stripped down to a core
> system upon which anything can be built. The classic model was the first
> thing implemented and works so your screen, navigation and layout templates
> can be used in Turbine
>>>>>>>>> .
> 
> I guess what I am wondering is whether the 'classic' templating model is
> what will be suggested for use with Turbine 3. The thing I like about this
> way of doing things, is that once you have setup layouts and navs, you don't
> have to worry about them anymore. Has anybody else found a better way to do
> templating, or is this still the best?

I think the idea is good but it definitely has the very strong disadvantage
of not streaming. All the output is buffered before being sent to the
browser which is bottleneck. I have seen this and Daniel has also notice
performance problems with this model. I myself am going to try and come up
with something that will be convenient like the classic model but stream
instead of buffer.

> 
> Gareth
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

-- 

jvz.

Jason van Zyl

http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Are navigation classes in for the same fate as screen classesin Turbine-3

[Daniel Rall <dl...@finemaltcoding.com>]

Jason van Zyl <jv...@zenplex.com> writes:

> I think the idea is good but it definitely has the very strong disadvantage
> of not streaming. All the output is buffered before being sent to the
> browser which is bottleneck. I have seen this and Daniel has also notice
> performance problems with this model. I myself am going to try and come up
> with something that will be convenient like the classic model but stream
> instead of buffer.

Yup, exactly.  Hopefully we can figure out a way to use something
almost exactly like the existing screen/nav/layout setup, while
streaming the output of each merge instead of buffering huge strings.
The buffering really slows things down, especially since the buffers
used by Turbine are created new for each use.  This really gives the
heap a work out (and because of that, your CPU as well).

In Apache's httpd, the Apache Portable Runtime (APR) deals with memory
management issues like this by using passing around pre-alloc'd pools
which server code can dip into whenever memory is needed.

Even though we could improve the performance of the existing code by
using pooled buffers, a streamy approach will yield much better
results.  I'm hoping we can do something like a queue of streams to
replace the old String creation non-sense.  :)

Daniel

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Are navigation classes in for the same fate as screenclassesin Turbine-3

[John McNally <jm...@collab.net>]

I wrote DirectRenderer and DirectClassicPipeline so that the response is
not created as a large String.  It is not required by the
layout/navigation/screen system.

john mcnally

Jason van Zyl wrote:
> 
> On 1/16/02 10:37 AM, "Gareth Coltman" <ga...@majorband.co.uk>
> wrote:
> 
> > Hi,
> >
> > Sorry about my previous post, it wasn't intended to go to the list, but it
> > doesn't matter!
> >
> > Anyway, Jason posted:
> >
> >>>>>>>
> > No problem. Turbine 3 at the core will have no knowledge of a screen,
> > navigation or layout but the model (the classic model) will still be a valid
> > usage pattern. Scarab is currently using Turbine 3 along with screens,
> > navigations and layouts. How you structure your view will be determined by
> > the collection of valves used. Turbine will be stripped down to a core
> > system upon which anything can be built. The classic model was the first
> > thing implemented and works so your screen, navigation and layout templates
> > can be used in Turbine
> >>>>>>>>> .
> >
> > I guess what I am wondering is whether the 'classic' templating model is
> > what will be suggested for use with Turbine 3. The thing I like about this
> > way of doing things, is that once you have setup layouts and navs, you don't
> > have to worry about them anymore. Has anybody else found a better way to do
> > templating, or is this still the best?
> 
> I think the idea is good but it definitely has the very strong disadvantage
> of not streaming. All the output is buffered before being sent to the
> browser which is bottleneck. I have seen this and Daniel has also notice
> performance problems with this model. I myself am going to try and come up
> with something that will be convenient like the classic model but stream
> instead of buffer.
> 
> >
> > Gareth
> >
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> --
> 
> jvz.
> 
> Jason van Zyl
> 
> http://tambora.zenplex.org
> http://jakarta.apache.org/turbine
> http://jakarta.apache.org/velocity
> http://jakarta.apache.org/alexandria
> http://jakarta.apache.org/commons
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>