hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: [HttpConn] another status update
Date Mon, 19 Mar 2007 19:12:13 GMT
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.

cheers,
  Roland


---------------------------------------------------------------------
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