1. Has it ever been considered to implement this as part of HttpClient?
Yes, it has and the idea has been turned down, if my memory does not
fail me. The consensus was that HttpClient should remain a HTTP
communication library and would not attempt to evolve into a browser of
a sort, a vacuum cleaner, or anything else.
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.
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..
2. I have seen an archiecture in JTidy (w3c.org), which I find quite handy. They have something called filters that can be registered into the request/respose flow and alter or amend it as needed. Consequently, they have implemented caching as a filter that returns the cached response if applicable.
I checked into HttpClient and found it almost impossible to introduce something similar - i.e. intercept the request/response flow, without directly hacking into the code. Am I missing something here, or is caching really not in the scope of HttpClient. Would it not make sense to introduce a concept like filters/interceptors (well, not in 2.0 I assume).
That sounds like a good idea for release 3.0. Still, any caching mechanism should still be out of scope in my opinion. This said, we happily accept useful code as officially unsupported contributions.
Cheers
Oleg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
