Julian,
thanks for chiming in.
What improvement would pluggability provide regarding the risks you
mentioned?
If it is non-pluggable and there is a bug in the cache implementation, most
users would notice it and so chances are good to get it reported and get it
fixed some day.
But if it is pluggable, it would be very hard to track since you would have
to ask every user what cache implementation he is using and you would have
to get used to that implementation so the risk to have a bug is multiplied
and the chance to get it reported and fixed is much smaller (simple FMEA of
the problem proofs this).
So my suggestion would be to have non-pluggable transparent caching (as all
along the way through the web could be transparent caches anyways), search
for a nearly bug-free implementation, and provide it as part of the RI. If
plugability would be necessary to provide a stable solution, then it would
be necessary to have pluggable internet, too, since the one you are using
currently could use a faulty cache, too... and I doubt you hava pluggable
internet. ;-) Even your JVM could be buggy or your OS. If Jersey is buggy,
switch to a different JAX-RS engine. Don't see the need to be plugable
*within* a JAX-RS engine. Pluggability is just an alibi to not being forced
to provide a bug free software in this case.
If it would be so hard to provide an implementation for the http Cache
paradigm, then there would be no squid and no ISA server.
Regards
Markus
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke_at_gmx.de]
> Sent: Samstag, 7. Mai 2011 13:26
> To: jsr339-experts_at_jax-rs-spec.java.net
> Cc: Santiago Pericas-Geertsen
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal to
> downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>
> On 06.05.2011 16:17, Santiago Pericas-Geertsen wrote:
> > Markus,
> >
> > Thanks for elaborating on your proposal. As I said in my previous
> message, I believe there are use cases in which this proposal can be
> useful. However, I think there are use cases in which it can be
> problematic.
> >
> > One such case is using the client API in a server environment (like
> an EE container). In this scenario, there could be hundreds of threads
> executing concurrent requests using the client API. Having a single,
> shared cache could actually result in worse rather better performance
> (with additional problems like disk usage, cache replacement policies,
> etc.). This is where the analogy with the web browser falls short IMO.
> Moreover, problems that result from _transparent_ features like these
> are incredibly hard to find, especially when (system) developers are
> not necessarily JAX-RS experts.
> > ...
>
> Well.
>
> HTTP caches not only live in User Agents, but also in intermediaries.
> So
> it's definitively *possible* to write well-performing cache
> implementations (Squid comes to mind).
>
> That being said, caching is totally non-trivial; and having a broken
> cache implementation may be worse than not having a cache at all.
>
> Maybe this is something that should be pluggable?
>
> Best regards, Julian