Casey,
We hope to freeze 3.3 for a release in the next weeks. If you feel the
changes are reasonably small and will not create problems - you can still
do it.
What about:
1. We copy the code from 3.3 as it is in jasper34 area ( except that we
rename the package ).
2. We make sure it builds and runs in 3.3 - with a minimal set of changes:
- copy jasper34.jar in lib/container
- edit server.xml and replace <JspInterceptor> with <JspInterceptor34 >
3. You can start making the optimizations, and I can start doing the
refactoring, making sure we keep everything functional.
4. In time we can merge the changes from 4.0, add the new interfaces
proposed by Mel, add a new generator and so on - while making sure the
tests are passing and jasper is stable.
This is unlikely to be finished before 3.3 is released, but we can make
sure we keep passing all the test suites and we can release milestones of
jasper34 for who needs the performance enhancements.
When the code is ready we can make a 3.3.1 release and replace the old
jasper ( and same for when ajp14 is ready ).
What I tried in proposals/jasper34 is just wrong and against the basic
ideas of "evolution" - and I realize that.
Just give me 2 days, I need to finish with xalan ( we just had the 2.1.0
release and I need to finish my work on it )
Costin
On Wed, 23 May 2001, Casey Lucas wrote:
>
> Costin & Craig,
>
> I agree with both of you. The optimizations that Craig mentioned are
> exactly the ones that I was hoping to add. Yes, the least fun part
> will probably be adding to the existing generator code. But, until a
> new generating architecture is in place, I think it would be good to
> go ahead and try to add the code to the existing jasper.
>
> When the next gen jasper gets a lot of momentum, we can add the
> tag related optimizations to it.
>
> -casey
>
> [EMAIL PROTECTED] wrote:
> >
> > On Wed, 23 May 2001, Craig R. McClanahan wrote:
> >
> > > I know Costin loves evolutionary change :-), and it's certainly a valid
> > > approach to Jasper.
> > >
> > > But there is also another approach we should consider - a green-field
> > > recoding of at least some of the major components (conforming to an
> > > agreed-upon overall architecture, of course).
> >
> > > NOTE: For most of the rest of the overall problem (the PageContext
> > > implementation, how Jasper fits in with the servlet container, and so
> > > on) evolution is probably a very reasonable strategy. On the compiler,
> > > though, I'm not so sure.
> >
> > If we are talking about the compiler ( or code generator ): I partially
> > agree, the current architecture will get a lot of pressure from more
> > complex optimizations or tricks.
> >
> > But before we can even start to change the generator we need to do the
> > initial refactoring and get the other components in order ( runtime, etc).
> > We can also get some optimizations in, and use that to learn what's needed
> > from a new generator architecture.
> >
> > I just don't think the new generator can happen in a 3.4 space - my goal
> > is just to enable an effort to rewrite it, and gather as much information
> > as possible about it's requirements.
> >
> > In any case - whatever happens in the current generator with regard to
> > generated code will still be usefull for any new generator architecture.
> > And if certain optimizations can't be done - that's even better, because
> > it would help us understand what's needed.
> >
> > I had big hopes for an XSLT based generator, and I still think it may be a
> > good way to implement the code generator - and I hope to hear other
> > ideas.
> >
> > Costin
>
