Voting sounds good for me.
Anyways, I was just consulted by Oracle about my opinion, so in the end Oracle can do what Oracle likes to do. I just wanted to express that the time I am sharing with this EG must not only be of any value for Oracle and Red Hat, but also for me / my customers, so I try to get the most out of it. If you don't want to go on now, this is ok for me, but then I have no more reason to go into the Client API in that depth as I did before. The sole reason to go into the Client API for me is just gone then, as this is the only thing I and my customers actually are missing compared to the solutions we currently have. If they have to use a proprietary cache, they can do without moving to JAX RS Client API. No need to answer, just to make you understand my persistence.
Regards
Markus
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Mittwoch, 18. Mai 2011 17:02
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Proposal to
> downgrade [JAX_RS_SPEC-39] Client Cache Support to MINOR
>
> Markus,
>
> I have a problem with making something so vague a mandatory spec
> feature. Also, from what I read, I tend to completely
> agree with Bill in this topic. Again, we need to nail this one down
> *now* and move along. So let's resolve this
> democratically and vote. Santiago will be sending an email with the
> poll details and instructions shortly.
>
> With that, I am withdrawing myself from this discussion until we have
> the final poll results.
>
> Marek
>
> On 05/17/2011 08:36 PM, Markus KARG wrote:
> > 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
> >>>>>>>
> >>>>>
> >>>
> >