I haven't posted here before, but I do follow the list closely, as well
as the code and the development efforts and have posted in the past on
other apache boards. I'm
hoping to get involved more directly with development issues (and bugs)
as we
prepare to move our application to TC3.x(where x>2).
As this particular discussion is of special interest I hope you don't
mind another voice.
See below.
Peter Donald wrote:
> >> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> >> One appropriate question to ask yourself, when comparing, is
> >> "what does having 15
> >> entry points give me that I cannot get with a single entry point
> >> approach"? If
> >> there is nothing significant, then it would seem cleaner to rely on a
> >> simpler-to-understand approach.
> >
> >That is a problem also found in several parts of business application
> >frameworks - those things that help you building a big User Interface
> >to manipulate and extract information from a big Database.
> >
> >You also find the same questions over GUI Frameworks - like Delphi's
> >VCL or Java's Swing. And in database interface libraries...
> >
> >In all of these you find events (Hooks) named "onThis", "beforeThat"
> >and "afterSomethingElse". And all this frameworks are built using
> >Object Oriented Programming Techniques.
>
> I think you are mixing concerns here. I have worked with multi entry point
> interceptors (what you call hooks) before and I *believe* that there are
> different levels of organisation that have to be examined. You mention GUIs
> here so I will address them here. For instance consider javas GUI awt.
>
> Under windows it gets it's events from a multitude of different sources
> (some are grabbed from eventqueue, others from win32 hooks and others are
> application created) then routes them through a central message queue and
> central dispatching model. In many ways the way it works is similar to
> hardwired valve style implementation. It is only at the upper layers where
> it is transformed into the
> preReleaseMouseButtonEventHookLudicrouselySizedMethod() and equivelent
> postRelease*().
Asynchronous messaging seems to be a very different animal to me than
the very synchronous execution model of the valve system as implemented
in catalina. Messaging guarantees event delivery and order of
delivery. It disconnects the cause and effect processes -- sometimes at
the expense of speed.
> The advantage of hooks is also the speed of development - ie it takes about
> 1/5 of the time to develope a hook based solution rather than a general
> solution. The general solution first has to be general and then it has to
> layer specificity on top of that (see below) which is even more work.
This seems backward to me. Abstraction shouldn't be carried farther
than it needs to go. The system is built in modular form, but that form
still has a very specific task. There are levels of modularity in OOD.
What is too specific to be allowed outside the application is necessary
internally. And what is too specific application wide is necessary
inside a module. Specificity of function is as much a part of OOD as
abstraction.
> >The advantage of Hooks is that the programmer is only exposed to the
> >very narrow complexity of a very specific event. The framework takes
> >care of the rest.
>
> Right but generally the good frameworks go
> specificity -> general -> specificty
This seems to describe TC3-HEAD, with the general interface for modules
being plugged (as interceptors) into specific parts of the
request/response processing.
I agree completely with the rest of your message, but, of course, those
changes have already been proposed at the time of my writing.
As always, I am open to instruction.
Thanks for helping me understand these issues better.
-Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
