As there is no JAX-RS Client API specification, there cannot be an implementation of it in the wild, obviously. I understand what you mean, but in fact, our application IS doing eager loading and it is working well. So why not adopting it as an option at least? I mean, we will get an API so we could get rid of our own implementation - but actually we cannot, since our's is doing caching and eager loading and lots more. I really am intrested what this EG will agree upon in the end. I assume there will be nothing left but the least common denominator of all existing proprietary clients - what would be more or less useless compared to any of the proprietary clients and such will never get adopted, as it will be not much more as a fluent replacement for HttpUrlConnection. Each of us MUST add some features not existing in his particular client yet, so the API will become a layer ONTOP the current feature set, not BELOW it. At least this is my vision of a common API.
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Montag, 8. August 2011 13:50
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: Hypermedia - Take 2
>
> I'm not sure of any JAX-RS implementation that currently supports eager
> loading, and, IMO, we should focus on features that have already had
> time to bake in the wild.
>
> On 8/6/11 1:43 PM, Markus KARG wrote:
> > Marek,
> >
> > certainly nobody wants to build a browser. I wrote that because I am
> convinced by my experience with our own business application that there
> are lots of things in a browser that application programmers will need
> or at least would like to see in a JAX-RS client engine, including the
> lenghthy discussed topics of caching and the current topic of eager
> loading. I understand that you think that eager loading makes no sense,
> but see, there are use cases where it does make sense, particularly in
> scenarios where heavily master-detail structural relations are used. So
> my opinion is that even if we decide for lazy loading as the default,
> there should be an option to get eager loading. Just as it is done in
> JPA between application server and database server, we need the same
> here between client and application server. And, as our experience is
> that the applications all had benefits from eager loading in some of
> the use cases (certainly not in all), we object that it is enough to
> have
> eager loading in the first draft, but vote for having also eager
> loading without programming it into the application itself.
> >
> > Regards
> > Markus
> >
> >> -----Original Message-----
> >> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> >> Sent: Freitag, 5. August 2011 10:58
> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> Cc: Markus KARG
> >> Subject: Re: [jsr339-experts] Re: Hypermedia - Take 2
> >>
> >> We are NOT writing a browser (that needs to always display the whole
> >> content in the end), we're writing a RESTful API.
> >> Should you be writing a browser, you could use the API and implement
> >> the "eager loading" or, more precisely "eager
> >> rendering" on top of it.
> >>
> >> Similarly, if you shoot for some speculative performance
> improvements
> >> based on the partial cached data, you should be
> >> able to implement it on top of the API. At least for now. Once such
> >> solution matures, we can consider putting into the
> >> API. For now, being able to conveniently add links on the server
> side
> >> and conveniently follow them on the client side is
> >> a good start IMO.
> >>
> >> Over and out,
> >> Marek
> >>
> >> On 08/04/2011 08:16 PM, Markus KARG wrote:
> >>> Even if we do not vote for eager loading as nobody but me seems to
> >>> see the benefit (BTW, Google just posted that their next Chrome
> will
> >> do
> >>> exactly that and even pre-render!)
> >
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com