On 8/3/06, James M Snell <[EMAIL PROTECTED]> wrote:
Garrett Rooney wrote:
> On 8/3/06, James M Snell <[EMAIL PROTECTED]> 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