I do not insist on any particular solution (neither properties nor filters),
I just want to reach that the spec defines exactly one portable way to
switch on a cache provided by the JAX RS vendor, not by the application
provider.
> -----Original Message-----
> From: Ng, Tony [mailto:tonyng_at_ebay.com]
> Sent: Dienstag, 17. Mai 2011 19:29
> To: jsr339-experts_at_jax-rs-spec.java.net
> Cc: Markus KARG; Bill Burke
> Subject: Re: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal
> to downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>
>
> Can we agree the to-be-defined client-side interceptor API will support
> the use case of plugging in a custom client-side caching solution?
>
> Thanks,
> Tony
>
>
> From: Marek Potociar
> <marek.potociar_at_oracle.com<mailto:marek.potociar_at_oracle.com>>
> Reply-To: "jsr339-experts_at_jax-rs-spec.java.net<mailto:jsr339-
> experts_at_jax-rs-spec.java.net>" <jsr339-experts_at_jax-rs-
> spec.java.net<mailto:jsr339-experts_at_jax-rs-spec.java.net>>
> Date: Tue, 17 May 2011 10:36:56 -0600
> To: "jsr339-experts_at_jax-rs-spec.java.net<mailto:jsr339-experts_at_jax-rs-
> spec.java.net>" <jsr339-experts_at_jax-rs-spec.java.net<mailto:jsr339-
> experts_at_jax-rs-spec.java.net>>
> Cc: Markus KARG
> <markus_at_headcrashing.eu<mailto:markus_at_headcrashing.eu>>, Bill Burke
> <bburke_at_redhat.com<mailto:bburke_at_redhat.com>>
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal to
> downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>
> Hello *,
>
> Can we agree on a ClientConfiguration.ENABLE_CACHING property? This
> would indicate that the JAX-RS implementation should
> enable it's caching feature if available. The spec would however not
> define any SLA for this feature and it would be up
> to the implementation to define its level of support for caching.
>
> Additionally, we would add Client.isSupported(String feature) that
> could be used in general to query the underlying
> implementation to check if a feature is supported.
>
> Based on the expressed opinions, I believe that this proposal is a good
> consensus. Given the time we already spent
> discussing this compared to other important stuff, it's time to close
> it and move on.
>
> Marek
>
>
> On 05/16/2011 06:50 PM, Markus KARG wrote:
> I do not agree that this vision is naive, since it a basic intention
> behind the Java platform. It is ambitioned, yes. It is complex, yes.
> But that's a difference. But it's not an excuse to ask for proprietary
> solutions.
> Proprietary extensions are inacceptable for such simple things like
> "enable local caching" and will just not get my vote. I accept that we
> agree on the smallest possible solution, but the solution must provide
> a working cache, and it must be 100% vendor independent. This includes
> omitting any proprietary class and property names, be it in source of
> configuration files. http Caches are a core feature of the http
> protocol, so I do not see that we need any proprietary evolution before
> we can provide a cross-vendor API to just enable it. You are right that
> we do not need to address any feature. But we must address cross-vendor
> WORA non-proprietary cache enabling. Just let people switch the cache
> on without anybody needing to change the boxed product. Not more do I
> ask for. But not less, too.
> Caching is one of the most important things on my list, so I'm sorry,
> but independent of what else we will do in this future, a JAX RS 2 spec
> without a vendor-independent way to enable caching will not get my
> vote. Just to make clear how essential this feature is for us.
> BTW, I do not understand what would be so bad with either
> Client.setFilter(Client.CACHING_FILTER)
> or
> Client.setProperty(Client.ENABLE_CACHE)
> ?
> Both ways are 100% WORA and allow the implementor to provide a
> proprietary cache of his choice, even a most minimal, even an existing
> popular one. Again, my target is just to prevent duplicate GETs so the
> implementation is not necessarily sophisticated. I do not enforce any
> specials.
> Regards
> Markus
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Montag, 16. Mai 2011 11:25
> To: Markus KARG
> Cc: jsr339-experts_at_jax-rs-spec.java.net<mailto:jsr339-experts_at_jax-rs-
> spec.java.net>; 'Bill Burke'
> Subject: Re: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal
> to downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>
> On 05/13/2011 08:16 PM, Markus KARG wrote:
> Exactly what I fight against! As a Java Expert Group our target must
> be that no proprietary API must be used.
>
> I disagree. It would be naive to think that we can put together an API
> that will solve all World's problems in its first
> version. Instead, we should aim for a minimalistic API design that is
> open to proprietary extensions and flexible to
> support future additions and extensions as part of the natural API
> evolution. We do not need to address every aspect in
> the first API version.
>
> Caching is a basic feature of http, and so it must be useable without
> proprietary stuff.
>
> Caching is also the most complex HTTP feature. There are many other
> important RESTful features on our plate. Do we
> really have to spend all our energy on this single topic now? Going
> with a proprietary extensions for now is a good
> option IMO.
>
> Marek
>
>
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Freitag, 13. Mai 2011 12:35
> To: jsr339-experts_at_jax-rs-spec.java.net<mailto:jsr339-experts_at_jax-rs-
> spec.java.net>
> Cc: Markus KARG; 'Bill Burke'
> Subject: Re: [jsr339-experts] Re: [jax-rs-spec users] Re: Re:
> Proposal
> to downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>
>
>
> On 05/12/2011 07:43 PM, Markus KARG wrote:
> Agreed, but in a standalone client application the application's
> http
> transport provider is provided by the JAX RS Implementation, isn't
> it?
> How should an application enable caching then?
>
> Through a proprietary client provider API.
>
> Marek
>
>
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Donnerstag, 12. Mai 2011 16:31
> To: jsr339-experts_at_jax-rs-spec.java.net<mailto:jsr339-experts_at_jax-rs-
> spec.java.net>
> Cc: Bill Burke
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal
> to
> downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>
>
>
> On 05/12/2011 01:49 PM, Bill Burke wrote:
> Caches are essential, but they don't necessarily belong in the
> JAX-
> RS
> specification.
>
> +1 for me it's actually one level down. The HTTP transport
> provider
> should take care of that.
>
> Marek
>
>