You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by Garrett Rooney <ro...@electricjellyfish.net> on 2006/08/04 19:48:31 UTC

Re: svn commit: r428793 [1/2] - in /incubator/abdera/java/trunk/client: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/abdera/ src/main/java/org/apache/abdera/protocol/ src/main/java/org/apache/

On 8/4/06, jmsnell@apache.org <jm...@apache.org> wrote:
> Author: jmsnell
> Date: Fri Aug  4 10:36:34 2006
> New Revision: 428793
>
> URL: http://svn.apache.org/viewvc?rev=428793&view=rev
> Log:
> This still needs LOTS of work to complete.  The client itself is rather straightforward and complete, conditional gets,
> cache-control, gzip/compress/zip compression is supported and enabled by default, extension HTTP methods (e.g. COPY)
> can be used with nominal effort..
>
> The part that really needs the most work is the client side HTTP cache.  It's generally functional but still needs lots of
> refinements, testing, tweaking... and a generally-better-all-the-way-around implementation.  The goal is to provide a functionally
> complete client-side private cache that supports most of the nuances of HTTP caching (e.g. Vary headers, max-stale, min-fresh,
> no-cache and private headers, and so on).  Use of the cache can be controlled via the RequestOptions interface
> (e.g. options.setNoCache(true) to disable the use of the cache via the Cache-Control header).
>
> I had imagined ultimately shipping three cache implementations with this.  An in-memory LRU cache, A write-to-disk cache, and a
> JCS-backed cache implementation.  Other impls are possible (e.g. derby-based, etc).
>
> The client code currently depends 100% on the Apache Commons HTTP Client. Changing the http stack would require fairly significant
> changes to this code.

Any chance of getting this hooked into the ant build?

Also, tests and/or example code would be useful, although I can
certainly understand how it would be hard to test the client without a
working server...

-garrett

Re: svn commit: r428793 [1/2] - in /incubator/abdera/java/trunk/client: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/abdera/ src/main/java/org/apache/abdera/protocol/ src/main/java/org/apache/

Posted by James M Snell <ja...@gmail.com>.

Garrett Rooney wrote:
> On 8/4/06, James M Snell <ja...@gmail.com> wrote:
>> Yeah, those are coming. Man you're picky ;-).
> 
> Was just a little surprised when I ran 'svn up && ant -f
> build/build.xml' and nothing happened ;-)
> ...

Check in the code, he says. Give me an ant build, he says. Give me
tests, he says.  Good grief.... ;-)

- James

Re: svn commit: r428793 [1/2] - in /incubator/abdera/java/trunk/client: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/abdera/ src/main/java/org/apache/abdera/protocol/ src/main/java/org/apache/

Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/4/06, James M Snell <ja...@gmail.com> wrote:
> Yeah, those are coming. Man you're picky ;-).

Was just a little surprised when I ran 'svn up && ant -f
build/build.xml' and nothing happened ;-)

> I rewrote the client
> yesterday following my initial post and thus still have to go through
> and rewrite my tests.  For now I've been testing the client against Mark
> Nottingham's set of XMLHttpRequest caching tests[1]. The ant build will
> be coming shortly.

Great!  Looking forward to it.

-garrett

Re: svn commit: r428793 [1/2] - in /incubator/abdera/java/trunk/client: ./ src/ src/main/ src/main/java/ src/main/java/org/ src/main/java/org/apache/ src/main/java/org/apache/abdera/ src/main/java/org/apache/abdera/protocol/ src/main/java/org/apache/

Posted by James M Snell <ja...@gmail.com>.
Yeah, those are coming. Man you're picky ;-).  I rewrote the client
yesterday following my initial post and thus still have to go through
and rewrite my tests.  For now I've been testing the client against Mark
Nottingham's set of XMLHttpRequest caching tests[1]. The ant build will
be coming shortly.

- James

p.s. don't expect much of the caching impl yet.  I'm pretty well certain
it's busted as is and will need lots of work to get right.  I really
hate the fact that there doesn't appear to be any Java language client
side cache implementations out there.

[1] http://www.mnot.net/javascript/xmlhttprequest/cache.html

Garrett Rooney wrote:
> On 8/4/06, jmsnell@apache.org <jm...@apache.org> wrote:
>> Author: jmsnell
>> Date: Fri Aug  4 10:36:34 2006
>> New Revision: 428793
>>
>> URL: http://svn.apache.org/viewvc?rev=428793&view=rev
>> Log:
>> This still needs LOTS of work to complete.  The client itself is
>> rather straightforward and complete, conditional gets,
>> cache-control, gzip/compress/zip compression is supported and enabled
>> by default, extension HTTP methods (e.g. COPY)
>> can be used with nominal effort..
>>
>> The part that really needs the most work is the client side HTTP
>> cache.  It's generally functional but still needs lots of
>> refinements, testing, tweaking... and a
>> generally-better-all-the-way-around implementation.  The goal is to
>> provide a functionally
>> complete client-side private cache that supports most of the nuances
>> of HTTP caching (e.g. Vary headers, max-stale, min-fresh,
>> no-cache and private headers, and so on).  Use of the cache can be
>> controlled via the RequestOptions interface
>> (e.g. options.setNoCache(true) to disable the use of the cache via the
>> Cache-Control header).
>>
>> I had imagined ultimately shipping three cache implementations with
>> this.  An in-memory LRU cache, A write-to-disk cache, and a
>> JCS-backed cache implementation.  Other impls are possible (e.g.
>> derby-based, etc).
>>
>> The client code currently depends 100% on the Apache Commons HTTP
>> Client. Changing the http stack would require fairly significant
>> changes to this code.
> 
> Any chance of getting this hooked into the ant build?
> 
> Also, tests and/or example code would be useful, although I can
> certainly understand how it would be hard to test the client without a
> working server...
> 
> -garrett
>