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