> What I find a little disappointing is the fact that I am faced with > almost unsurmountable obstacles in doing this (i.e., if I want to avoid > hacking the code). Maybe someone with a better understanding of the > architecture has a suggestion.. >
Believe me, I am also REALLY unhappy with the existing architecture. The present generation of HttpClient developers simply inherited the existing architecture from previous ones and ended up having to maintain the present APIs (even though we all find it sub-optimal) because a sizable group of users had been using HttpClients CVS snapshots for months before the API was formally frozen. At the moment there's simply no way around forking HttpClient if you want to bend its design in certain ways. I personally maintain a fork of my own because certain things my clients wanted could not have been implemented using Jakarta Commons' official version. Our plan is to release 2.0 beta2 as soon as possible, branch out 2.0 release, and start fixing known architectural flaws in CVS head. So, bear with us for a while. Good things come to those who wait. Not just Guinness, but also a more flexible HttpClient architecture. If you can't afford waiting, a code fork is your only resort. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
