abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <roo...@electricjellyfish.net>
Subject Re: FYI, client code
Date Thu, 03 Aug 2006 18:10:49 GMT
On 8/3/06, James M Snell <jasnell@gmail.com> wrote:
> Garrett Rooney wrote:
> > On 8/3/06, James M Snell <jasnell@gmail.com> wrote:
> >> Just a heads up... Next week I'll be checking in a new module that
> >> provides an APP client API.  Right now, the module is a fairly thin
> >> wrapper on top of the commons http client, but adds a client-side HTTP
> >> cache and easier support for conditional operations.
> >
> > Any reason you haven't been developing this in the tree, as opposed to
> > dropping a mostly completed module on us?  Seeing the development of
> > such things is useful, as it's often easier to digest code
> > incrementally as opposed to having to start from the completed
> > version...
> >
>
> Mainly because the code is currently embarrassingly sloppy and I really
> just started working on it in earnest yesterday morning.

Ahh, ok.

> >> For example,
> >>
> >>   // prepare the request
> >>   Client client = ClientFactory.INSTANCE.newClient();
> >>   ClientRequestContext rc =
> >>     client.createRequestContext(
> >>       "GET","http://www.snellspace.com/wp/wp-atom1.php");
> >
> > Yet another factory?  Is that really necessary?
> >
>
> Likely not. There are two motivations: 1. allow for other underlying
> client stack impls (e.g. something other than commons httpclient) and 2.
> align with the model used by the rest of Abdera.  We likely should take
> a look at the model used across the entire code and see if a better
> approach can be applied across the board.

I just worry that it's less likely that you'd want to switch http
client impls than underlying XML parsers.  The only particularly
interesting reason I can think of to switch http clients might be to
use something like AsyncWeb, and allowing that would likely require a
rather different API than something like commons httpclient...

> >>   // execute the request
> >>   ClientResponseContext resp =
> >>     (ClientResponseContext) client.process(rc);
> >>
> >>   // check the status
> >>   System.out.println(resp.getStatus());
> >>
> >>   // a second request will pull the response from the client cache
> >>   // Cache-Control directives are respected. Stale cached responses are
> >>   // revalidated.
> >>   resp = (ClientResponseContext) client.process(rc);
> >>
> >>   System.out.println(resp.getStatus());
> >>
> >> There are still lots of little issues to work out, such as whether or
> >> not to buffer the InputStream coming from the commons HttpClient so that
> >> the connection can be released, but, for the most part, I've got the
> >> client code working.
> >
> > Again, it seems like this kind of thing could be "worked out" in the
> > repos and on this list, unless that's what you mean and I'm
> > missunderstanding...
> >
>
> Yeah, that's what I'm meaning.  The code I check in will be minimally
> functional (just enough so that it appears to work) and will need quite
> a bit more work.

Cool, looking forward to seeing the code.

-garrett

Mime
View raw message