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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
