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