You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by James M Snell <ja...@gmail.com> on 2006/08/03 19:44:23 UTC
FYI, client code
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.
For example,
// prepare the request
Client client = ClientFactory.INSTANCE.newClient();
ClientRequestContext rc =
client.createRequestContext(
"GET","http://www.snellspace.com/wp/wp-atom1.php");
// 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.
- James
Re: FYI, client code
Posted by Paul Querna <ch...@force-elite.com>.
James M Snell wrote:
> Garrett Rooney wrote:
>> On 8/3/06, James M Snell <ja...@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.
>
FWIW, I believe it is best for embarrassingly sloppy code to go into a
svn branch for the new module/feature, rather than it just getting
plopped down when its 'done'.
Yes, before it is merged to trunk, it will need more code review, but it
allows others to be involved in the earlier design of the module, which
generally results in something better at the end.
-Paul
Re: FYI, client code
Posted by James M Snell <ja...@gmail.com>.
Garrett Rooney wrote:
>> [snip]
>> Mainly because the code is currently embarrassingly sloppy and I really
>> just started working on it in earnest yesterday morning.
>
> Ahh, ok.
>
There's madness to my method, for sure. :-)
>> [snip]
>> 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...
>
You're likely right here and it would greatly simplify the code if we
just said, "We're writing code for the Commons client, period.", which
is fine for me.
- James
Re: FYI, client code
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/3/06, James M Snell <ja...@gmail.com> wrote:
> Garrett Rooney wrote:
> > On 8/3/06, James M Snell <ja...@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
Re: FYI, client code
Posted by James M Snell <ja...@gmail.com>.
Garrett Rooney wrote:
> On 8/3/06, James M Snell <ja...@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.
>> 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.
>> // 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.
- James
Re: FYI, client code
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/3/06, James M Snell <ja...@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...
> 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?
> // 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...
-garrett