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]
> > >
> >
>
