Marek,
sounds pretty good, but despite "should" and "isSupported" I would propose "must" and the providing a micro cache implementation with the RI instead. It could be as small as just preventing identical GETs and hold only the past ten or twenty GETs to be effective. This would not impose any real costs to vendors, but it would bring a much higher benefit to the users.
Regards
Markus
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Dienstag, 17. Mai 2011 18:37
> 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
>
> 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; '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
> >>>> 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
> >>>>>> 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
> >>>>>
> >>>
> >