"Craig R. McClanahan" wrote:
>
> Paul Speed wrote:
>
> > [EMAIL PROTECTED] wrote:
> > >
> > > Can you argue about how Valve's single chain of command ( where
> > > authentication, generation, etc are done in a single invoke() ) can
> > > be better than what all other server are doing ( and Apache 2.0
> > > moves to a different level with the flexible HOOK mechanism ?
> > >
> >
> > Actually, this is a discussion I would like to see happen. I
> > think that I can actually argue for Valves. Admittedly, I know little
> > about the actual implementations but I am very familiar with the
> > patterns used in Tomcat 3.x and Tomcat 4.x and I have seen much of the
> > discussions on this list. However, in other projects I have converted
> > several architectures using patterns similar to 3.x to be more like the
> > Valve approach. We did it to shorten development times and improve
> > developer productivity. Performance wasn't our main goal but in all
> > but one case performance improved.
> >
>
> Valves implement the "Chain of Responsibility" design pattern in the GoF book.
> You will also see a very similar programming model in the way that the
> javax.servlet.Filter APIs are defined in the Servlet Specification, Version 2.3
> Proposed Final Draft -- after wrestling with lots of alternatives, the expert
> group concluded that this was the most appropriate programming model for
> exposing similar functionality at the application level.
Yeah, I've used variations on this pattern to help save architectures
that were spiralling out of control.
>
> >
> > What I would like to see is a frank analysis of this topic.
> > If those "in the know" do not have the time then I will attempt to
> > do a brief analysis myself in the coming weeks. It will take research
> > on my part whereas some of you might know the answers off the top of
> > your head.
> >
>
> I did an analysis on this topic in August, when Catalina was being formally
> proposed -- it is still in the "jakarta-tomcat-4.1" CVS repository as file
> "catalina/docs/filters.html". The comparison was primarily to the way that
> request interceptors were implemented in Tomcat 3.2, so I would suspect that
> there have been some changes since on the HEAD branch -- particularly in the
> last section, where I discuss limitations that are due to the *implementation*
> of request interceptors in Tomcat 3.2, not their *design*. (The Valve APIs have
> not needed to be changed -- they have proven to be entirely sufficient to
> implement the servlet 2.3 spec's functionality requirements :-).
>
> Aside from downloading the 4.1 source repository, this document will also be
> visible though the online CVS web access. Sorry, I'm offline at the moment, so
> I cannot give you a hyperlink, but select the CVSWeb link, module
> "jakarta-tomcat-4.1", directory "catalina", directory "docs", directory "dev",
> and file "filters.html".
Just in case anyone else is interested:
http://jakarta.apache.org/cvsweb/index.cgi/jakarta-tomcat-4.1/catalina/docs/filters.html
>
> >
> > What I intend to compare is the typical method call sequence
> > of the two approaches, including resource allocation if any, when
> > handling various types requests. From there I hope to point to the
> > relative merits and tradeoffs of each approach.
> >
> > I have fun with this kind of stuff... it harkens back to
> > my old graphics programming days. It's almost always surprising
> > what this stuff will turn up.
> >
> > -Paul Speed
> >
>
> I had a Comp Sci prof that made an interesting point -- you only write one real
> program in your life, and then you spend the rest of your career plagarizing
> from it :-)
Ain't it the truth. One thing that was always fun about graphics
programming was that quite often the algorithm that looked least
optimal performed the best. Figuring out why is sometimes it's own
game.
Thanks for the pointer to the doc... it should get me started.
-Paul Speed
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
