hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Sutton <adr...@intencha.com>
Subject Re: HTTP client caching
Date Wed, 25 Jun 2003 22:24:48 GMT
> well, a vacuum cleaner is indeed a bit far off ;-). However, I think 
> that implementing an Http Client (i.e. a browser emulator without 
> rendering engine) should be much closer to HttpClients purpose.

I would actually think that a nice generic caching library would be 
very beneficial, but it should definitely be outside of HttpClient as 
HttpClient is very regularly used without any desire for caching at 
all.  That said, a caching library could either be provided in 
HttpClient's contrib directory if it was small and not too actively 
developed, or if it gets really active or get a lot of use it can be 
moved over to the commons-sandbox to start life as an independant 
component.  Alternatively, if there is an interest straight away it 
could start in the commons-sandbox, it does seem to have a wide enough 
scope to warrant it's own component.

We actually need something like this for a future version of our 
product (1-2 months time maybe) so I'd be interested in helping out and 
can definitely act as the "committer gateway" to review submissions and 
get them into CVS etc.

> What I find a little disappointing is the fact that I am faced with 
> almost unsurmountable obstacles in doing this (i.e., if I want to 
> avoid hacking the code). Maybe someone with a better understanding of 
> the architecture has a suggestion..

There shouldn't be any obstacles in your way to implement caching.  You 
will have to manually add the headers for last-modified etc, but that's 
all quite simple with the current HttpClient APIs.  If you can give a 
little more detail about what obstacles you're hitting I can probably 
point out how to get around them.

Regards,

Adrian Sutton.


Mime
View raw message