Oleg Kalnichevski wrote: > With all due respect I do not think this solves any real _practical_ > problem, but merely rearranges things more to your personal liking.
It sure has to do with personal liking to some degree. But currently, if I want to replace the parser for the protocol version spec, I have to do the following (rough guess): - write the new parser replacing the one in BasicHttpVersionFormat - copy&modify the parser in BasicRequestLine and/or BasicStatusLine, to call my new parser instead of the default one - define a new HttpRequestParser and/or HttpResponseParser to call the modified parser from the previous step - define a new connection class that creates my new parser - define a new operator that instantiates my new connection class That is a lot of wrapping code for a little change in functionality. Static methods are notoriously hard to replace, and that is why I don't like them. Supporting SIP may be a pointless exercise or not, but we'll never be able to tell until we've done it. I consider it a good test case for the flexibility of the framework. HTTPCLIENT-661 is a real-life example where replacing a parser would solve a user problem. A bit further back, we also had a real-life problem where a user needed to communicate with a broken server that sent a second status line in the headers.[1] No problem if users can easily plug in tolerant parsers for the headers. > I can live with that and will not stand in your way. > But I want to ask you of two things: > > (1) I invested A LOT of time and efforts into ensuring that parsing and > formatting code generates nearly no intermediate garbage on the heap and > is quite fast. It would be very regrettable if these code optimizations > are lost ACK. > > (2) Please try to keep parsing and formatting logic in HttpCore base and > NIO code logically consistent. I will. The idea is to collect the static methods into classes with non-static ones, while keeping the actual parsing and formatting logic unchanged. Everything currently static is stateless so only one instance of each class has to be created. The part where state comes into play is the header continuation parsing, which currently already requires one object per message to be instantiated. I don't plan to change that significantly. At best, I can factor out the currently duplicated code for header continuation parsing, making base and NIO even more consistent. I'll provide patches for review some time next week. cheers, Roland [1] http://mail-archives.apache.org/mod_mbox/jakarta-httpcomponents-dev/200608.mbox/[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
