As this is a democratic forum, I will not be able to stop you from doing that. ;-)
But for the reasons you wrote I need to tell you that I do not see any better suited working group, as (AFAIK) there is no group working on a generic http client (which would be the right place if I get you right). For me it looks more like "Uh, what a lot of complex work. Let's skip that and never again talk about it." ;-)
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Montag, 9. Mai 2011 17:07
> To: jsr339-experts_at_jax-rs-spec.java.net
> Cc: Markus KARG
> Subject: [jsr339-experts] Re: Proposal to downgrade [JAX_RS_SPEC-39]
> Client Cache Support to MINOR
>
> Hi Markus,
> I gave it more thought and read carefully through all the messages in
> this thread.
>
> JAX-RS specification does not seem to be the right platform for
> defining a standard client-side caching API. HTTP
> caching API is quite complex and coherent domain that deserves it's own
> JSR with a dedicated EG formed of experts
> specialized on caching domain. Once such JSR is finalized JAX-RS could
> be updated to reference it.
>
> Such approach would be well aligned with the past JAX-RS as well as
> overall Java EE platform strategy. Consider e.g.
> data binding APIs used in JAX-RS. Data bindings (e.g. JAXB, JSON),
> while playing an essential role in JAX-RS, are not
> defined in the scope of JAX-RS API spec and are covered by separate
> JSRs instead.
>
> Since we failed to reach (or at least come close to) a consensus about
> this being a CRITICAL issue we need to downgrade
> the issue for now. Instead of spending more effort in attempts to find
> a common ground in this matter, we should switch
> our focus to other critical tasks and issues where we do have a common
> agreement about their importance and defer the
> client-side caching API issue to future reconsideration.
>
> Marek
>
>
> On 05/07/2011 06:09 PM, Markus KARG wrote:
> > I understand what you like to tell, but still do not see the problem.
> If I
> > would not implement features just because it imposes to use my brain
> and
> > spend lots of time, I should not go into office at the mornings. This
> is
> > Oracle in the end, so who if not them should provide a Java based
> cache? If
> > we all fear to fail all the time, we better not start with anything.
> >
> >> -----Original Message-----
> >> From: Julian Reschke [mailto:julian.reschke_at_gmx.de]
> >> Sent: Samstag, 7. Mai 2011 16:32
> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> Cc: Markus KARG
> >> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal
> to
> >> downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
> >>
> >> On 07.05.2011 15:44, Markus KARG wrote:
> >>> Decoupling is just a means to get a particular improvement, not an
> >>> improvement by itself - but it is added complexity and such adds
> >> possible
> >>> cause of failure. So what will *this* decoupling actually provide
> >> *here*,
> >>> despite the problems I already mentioned in my last posting?
> >>> ...
> >>
> >> Well, decoupling would require us to define a proper caching API,
> which
> >> isn't trivial, but might help implementers get their code right.
> >>
> >> Consider all the things you have to get right:
> >>
> >> - properly handling Conneg (Vary...)
> >> - special casing Cookies
> >> - working around server bugs with compression
> >> - properly handle extension status codes/methods
> >> - invalidation
> >> - heuristic expiry
> >> - parsing Cache-Control/Pragma
> >> - range requests
> >>
> >> etc.
> >>
> >> Don't get me wrong, it would be awesome to get a clean Java
> >> implementation of the HTTP caching model; optimally following what
> the
> >> HTTPbis WG is doing in
> >> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p6-cache-
> 14.html>.
> >>
> >> Best regards, Julian
> >