Yes I have seen that but I think that is too complex. Whether or not a
client application is using GZIP is, in my opinion, dependend of several
factors, most essential: The target resource and the use case. For example,
if I am posting photos to a server and those are very small
artifact-disturbed portrait thumbnail JPGs already, I won't add GZIP ontop
as it might even enlarge data or in the best case it just wastes CPU time.
But it might be possible to post huge x-ray scan TIFFs to the same resource,
so I want to add GZIP to shrink them lossless. On the other hand, my
application might have the need to log all PUTs of X-rays for juristic
reasons, while nobody cares about logging simple user thumbnails. So that
application is best fitted using something like
client.post(myEntity).to(myURL).using(someFilter).and(someCompression).later
(); // or now();
which is much more fluent to read than any proposal seen so far, or as a
different proposal
toWebResource.post(myEntity).applying(someFilter, someCompression).later();
// or now();
Especially it has nothing to do with changing the config, neither in a
static or dynamic way, as a dynamic config change is not agile enough for
this type of application and might induce negative side impact on parallel
running threads in different use cases (at least you must either block that
other thread to not check the config until the config change is done, or you
need to block the config changing thread to wait until the running thread is
done -- independent of why is waiting, what you come out with in the end is
a nice race condition).
Regards
Markus
From: Santiago Pericas-Geertsen [mailto:Santiago.PericasGeertsen_at_oracle.com]
Sent: Montag, 13. Juni 2011 16:19
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Updated Client API and
Interceptors/Filters proposal is available - please review
On Jun 12, 2011, at 12:01 PM, Markus KARG wrote:
If you seen the list of example interceptors I gave on my blog you'll
see that they are mainly for feature development not application
development.
Sure, but as you can see in the above quote, my comment was about Client
programmers. I understand that feature programmers would love the
annotations way to register their feature, but I expect most of the Client
API users being non-feature programmers. We should provide not only powerful
means to feature programmers, but we first should concentrate on making the
Client programmer's life easier.
Did you see the example in the wiki [1] that shows how to add
filters/handlers to a ClientConfiguration instance?
-- Santiago
[1]
http://java.net/projects/jax-rs-spec/pages/InterceptorsAndFilters