On Tue, May 6, 2008 at 3:59 PM, Paul Lindner <[EMAIL PROTECTED]> wrote:
> Sticking with 3.x is fine with me. > > We are seeing good performance from this in production for proxying, it > does > a very good job maintaining the connection pool. Now I just have to > convince all our partners to support keep-alive. Let me know if you have any luck with that -- supporting keep-alive would probably be the single biggest overall performance improvement that can be made for opensocial implementations. Streaming would be a nice to have as well (and I think someone opened a JIRA ticket for this). > > > FYI - There is a maven repo for snapshot builds > > > http://people.apache.org/repo/m2-snapshot-repository/org/apache/httpcomponen > ts/httpclient/<http://people.apache.org/repo/m2-snapshot-repository/org/apache/httpcomponents/httpclient/> > > > On 5/6/08 2:30 PM, "Kevin Brown" <[EMAIL PROTECTED]> wrote: > > > On Tue, May 6, 2008 at 2:07 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > >> There doesn't seem to be a maven repository for httpclient 4.0 yet. I > >> can upgrade OAuth, but if repo.maven.org doesn't have 4.0 yet I wonder > >> whether it is ready for prime-time. > > > > > > Even though I really like the httpclient 4 design (I'd actually remove a > > large portion of our code and use that stuff in place), it's probably > not > > viable to use it due to versioning conflicts. We should revisit this > > sometime after the first stable release, though. For now I am going to > move > > us to using HttpClient by default, just using the 3.x version until 4.x > > becomes viable. > > > > > >> > >> On Sun, May 4, 2008 at 2:09 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > >>> Hey Paul, > >>> > >>> I can't seem to get 4.0 working at all because it conflicts with the > >>> httpclient-3.1 dependency in OAuth (which is a part of a sub package > >> that we > >>> don't even use...). Have you figured out a way around this? > >>> > >>> > >>> > >>> On Mon, Apr 28, 2008 at 4:04 AM, Paul Lindner <[EMAIL PROTECTED]> > wrote: > >>> > >>>> On Mon, Apr 28, 2008 at 02:59:57AM -0700, Kevin Brown wrote: > >>>>> > >>>>> > >>>>> I had a JIRA issue open to migrate to HttpClient instead of using > >>>>> URLConnection, but I was still leaning towards a wrapper interface > >> of > >>>> some > >>>>> sort for various reasons, the main one being that the older > >> HttpClient > >>>>> interface was difficult to extend. I haven't looked at the 4.0 > >> interface > >>>>> yet, but I trust your judgment. > >>>> > >>>> I've attached our implementation. (Please note that this was coded > >>>> under duress, so it could stand to be cleaned up a bit..)) > >>>> > >>>> It appears that oen could extend HttpClient with their concept of > >>>> built-in interceptors to implement most of the features we want. > >>>> Here's a sample that injects the Accept-Encoding header into outbound > >>>> requests: > >>>> > >>>> // Add hooks for gzip/deflate > >>>> client.addRequestInterceptor(new HttpRequestInterceptor() { > >>>> public void process( > >>>> final HttpRequest request, > >>>> final HttpContext context) throws HttpException, > >>>> IOException { > >>>> if (!request.containsHeader("Accept-Encoding")) { > >>>> request.addHeader("Accept-Encoding", > >> "gzip,deflate"); > >>>> } > >>>> } > >>>> }); > >>>> > >>>> > >>>>> One of the big things I think we should do is drop the tight > >> coupling of > >>>> the > >>>>> auth modes to the http retrieval, and instead have something > >> dedicated > >>>> to > >>>>> dealing with various types of auth. Packing oauth and request > >> signing > >>>> into > >>>>> the fetchers was an interesting experiment, but the end results are > >>>> barely > >>>>> better than the previous revisions where stuff was crammed into the > >>>> proxy. > >>>>> Now that there are multiple places where auth needs to be done, > >> it's > >>>> even > >>>>> uglier to deal with. I think a bunch of us had good ideas here, but > >> they > >>>>> didn't really mesh well together and the end result is pretty poor. > >>>> > >>>> Okay. Sounds like it might be possible to factor out the > >>>> auth/signing code and then write adapters (like you see above) to > >>>> loosely integrate the pieces. > >>>> > >>>>> There's no time like the present to fix this stuff up, I suppose, > >> since > >>>>> changes in the last few weeks, and those coming in the next few are > >>>> dramatic > >>>>> enough that anyone doing heavy integration work is already in for a > >>>> rough > >>>>> patch. > >>>> > >>>> Ooof. Anything we can do to make this easier will be welcome. > >>>> > >>>> > >>>> -- > >>>> Paul Lindner > >>>> hi5 Architect > >>>> [EMAIL PROTECTED] > >>>> > >>> > >> > >
