Re: [Wpg-proxy-development] design details and impact on unittesting

[Alan M. <a_j...@ya...>]

Hi All,

adding my 2c based on what we have discussed
already....

> Currently the HttpMessageProcessor does the
> following three methods for each
> request and response if registered
[snip] 
> The goal of this interface is to allow the
> programmer to either modify the
> message with the process method before allowing it
> to continue down the
> line, to filter this message via the doSend and
> doContinue methods, or both.
> Based on the usage and definitions a better name is
> needed to keep confusion
> to a minimum.  
> I think this interface and all references to it
> would be better named
> “Filter” or “Translator”  What do you guys think????

I think that Filter or Handler (or even Processor) are
fine names that convey that idea of one step in a
sequence or chain of events.  I think each processor
(or whatever we call it) needs a well defined
lifecycle concerning what is does (not how it is
called, i.e., if it is to continue then this is a
decision to be made its calling context etc.)
 
> Second, the HttpMessageListener is not a listener
> and needs to be refactored
> based on that, also the error methods need to be
> rearchitected to be
> cleaner, and the received methods are confusing and
> ugly.  This whole thing
> needs redesign.

Agreed.  Listener makes it sound like an Observer
which it is not! In fact I kinda doubt the
processor/listener distinction is in fact a real
one...but I will study the code some more and touch up
my UML tomorrow.
 
> Currently HttpMessageListener looks like this:
> 
> 1.	void failed( Exception e ) // failed to even
> receive a request from
[snip...etc.]

The passage of Exceptions as arguments is a first for
me - I'm not sure whether I should laugh or
cry...anyhow the listener/processor needs only to
notify exceptions (i.e., throw them) and the calling
context should decide what to do.  Here are two
possibilities:

1. throw/catch with the option of passage the matter
back to the proxy client (not very nice since the user
may not want to get involved in that sort of thing)

2. define an ExeptionHandler that defines callbacks
for each type of exception that can be raised.  The
binding of callback to exception is typical template
method stuff and can be managed in a base class.  The
client code can optionally implement an
ExceptionHandler (failure to do so means a default one
is used) etc.  An example of this sort of thing is the
ErrorHandler that one sees with SAX parsing
architectures.

> Next, the received methods which are overloaded to
> handle both requests and
> responses should probably be renamed receivedRequest
> and receivedResponse
> respectively to clarify when each is called.  Then
> the error handlers should
> be less overloaded and more descriptive in their
> calling state.  In that
> vein, should we create a hierarchy of Exceptions to
> organized the errors
> causing the call, or an error enumeration to help
> organize the messages?  

The idioms of request/response handling ought to
follow those that most developers would be familiar
with in NIO or similar - so we can just take our lead
from that perhaps.  

Exceptions are typed so that we can distinguish error
events - we can easily afford to define a handful of
exceptions (perhaps based in a single class), this
sort of exception hierarchy is common and might even
be expected of us.  It would also bind nicely to the
ExceptionHandler suggestion above if we choose to go
down that route.  Not so sure about the enumeration -
that is not very Java-ish, better define types instead
(i.e., classes.)  Each exception class should of
course contain message information about the errors
etc. and should support all the usual features of
exceptions classes (e.g., support throwable, nested
exceptions etc.)

I think we should brace ourselves for a bit of a
rewrite of the interfaces but from I have seen of
John's stuff already I think that much of the
internals can be kept.  In all once we have a robust
API then the refactor itself will take no time at all.

hth,
A.


		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de