jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal to downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR

From: Bill Burke <bburke_at_redhat.com>
Date: Tue, 17 May 2011 13:36:31 -0400

+1, but I don't see how this affects this proposal. Plugging in a cache
would be:

Client.setProperty(ENABLE_CACHING, false);

Client.addABunchOfInterceptors(...my caching stuff...);

(Hope my pseudo code is getting my point across).

On 5/17/11 1:28 PM, Ng, Tony wrote:
>
> 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
>
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com