hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpConn] another status update
Date Mon, 19 Mar 2007 22:30:07 GMT
On Mon, 2007-03-19 at 20:12 +0100, Roland Weber wrote:
> Hi Oleg,
> 
> as usual, our opinions differ...
> 
> > (1) I tend to dislike static helper methods in examples, because they
> > disrupt the linear control flow and make code more difficult to read
> > IMO. Samples do not have to be very code efficient.
> > 
> > May I inline all private static helper methods in the samples?
> 
> Please do not. The samples for using an operator are meant to show
> how to use an operator. The same goes for the samples on using a
> manager, or the client. I trimmed the main() methods down to contain
> exactly that code, and as little besides as possible. Setting up
> parameters and protocol schemes is necessary ado to make the examples
> executable, but it distracts from what is exemplified. That is also
> why these helper methods are after the main method and not before.
> I would hope that this kind of examples encourages newcomers that
> rely on them to structure their applications, rather than to hack
> everything into one big method because they have no guidance on what
> should reasonably be moved into a helper.
> 
> > (2) May I change the samples to make use of HttpRequestExecutor instead
> > writing and reading stuff directly to and from the connection objects? I
> > think we ought not encourage the direct use of connection objects by the
> > end users.
> 
> Are you talking about the examples that show how to use a connection
> on a low level :-? Assuming that the request executor is prepared in
> a helper (;-), I have no problem with the sample request being executed
> that way. Except maybe that it requires more ado, like initializing the
> context. But if that is consistenly the same code in all examples, it
> shouldn't hurt.
> I have some reservations about sending the tunnelling requests
> through the same executor, although that is just a gut feeling for
> the moment. My understanding of what request and response processors
> should be used for and what not has undergone some changes during
> the work on HttpConn and HttpClient. The uneasiness might pass away.
> If you feel comfortable with it, that's good enough for me.
> 
> > (3) I would like to add logging decorators for HttpDataReceiver and
> > HttpDataTransmitter interfaces, so we could have the convenience of wire
> > logging, which I find very useful when developing new stuff.   
> 
> I put a TalkativeSocketFactory in the HttpClient contrib code to achieve
> a similar result, but I never was satisfied with that plug-in point,
> and it would not work well for layered connections. Please go ahead.
> Btw, when I used that approach, it seemed that some characters in the
> header were being written one by one rather than buffered. I don't
> recall what exactly it was, it might have been a header name.
> 

I'll leave the samples alone.

Oleg

> cheers,
>   Roland
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message