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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
