I do not see a need for that.
> -----Original Message-----
> From: guilherme.silveira_at_gmail.com
> [mailto:guilherme.silveira_at_gmail.com] On Behalf Of Guilherme Silveira
> Sent: Dienstag, 12. Juli 2011 16:58
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
>
> Hi Markus,
>
> I got it now. A detached Invocation-alike instance support for
> Resource based mappings. Wouldn't it be better to make it more generic
> and support any kind of detached support then? i.e.:
>
> > ClientFactory f = ClientFactory.instance();
> > f.enableFeature(x);
>
> > Client client = ClientFactory.create()
> > c.enableFeature(y);
>
> > Invocation i = client.post();
> > i.enableFeature(z)
>
> > DetachedInvocation i = Prepare.from(URL);
> > i.enableFeature(z);
>
> > i.queue(r);
>
> where
> DetachedInvocation := Invocation - execution methods
>
> So it gives support not only to Resource based warming up of objects,
> but anything like:
>
> zippingHeaders = Prepare.withHeaders(...)
> commonFeatures = Prepare.with(Feature1.class).with(Feature2.class)
>
> Invocation i = ClientFactory.create().get().post(); // the same as your
> code
>
> i.queue(zippingHeaders.with(commonFeatures));
>
> Regards
>
> Guilherme Silveira
> Caelum | Ensino e Inovação
> http://www.caelum.com.br/
>
>
>
> On Wed, Jul 6, 2011 at 4:22 PM, Markus KARG <markus_at_headcrashing.eu>
> wrote:
> > (using fancy method names, not aligned with any proposal)
> >
> > ClientFactory f = ClientFactory.instance();
> > f.enableFeature(x); // enables feature x for all clients to prevent
> > repeating
> > Client client = ClientFactory.create()
> > c.enableFeature(y); // enables feature y for this client only, other
> clients
> > must not have this enabled.
> > Invocation i = client.post();
> > i.setHeader(...);
> > Resource r = Resource.from(URL);
> > r.enableLogging(); // all access to this resource must be logged, but
> not
> > other resources
> > i.queue(r);
> >
> > If you do it with less interfaces, you would enable logging on other
> > resources, too, or you have to repeat the logging enablement with all
> > resources (creates log clutter), or you would enable feature y on all
> > clients (even if not wanted there, especially in server side client
> API
> > usage where another client is needed for a different application), or
> you
> > would have to repeat enableFeature(x) for all clients.
> >
> > So, how you like to solve that?
> >
> > Regards
> > Markus
> >
> >> -----Original Message-----
> >> From: guilherme.silveira_at_gmail.com
> >> [mailto:guilherme.silveira_at_gmail.com] On Behalf Of Guilherme
> Silveira
> >> Sent: Dienstag, 5. Juli 2011 20:41
> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
> >>
> >> > Because a user might like to configure *all* requests upon a
> resource
> >> > without the need to repeat that with each invocation. If you use
> the
> >> URL
> >> > class, you cannot do that, since the URL class is not
> configurable.
> >> I still can't see why he wouldn't be able to do that with 3
> >> interfaces, can you show me the code that is possible within the
> >> current approach? And I try to write with three interfaces?
> >>
> >> Regards
> >>
> >> Guilherme Silveira
> >> Caelum | Ensino e Inovação
> >> http://www.caelum.com.br/
> >>
> >>
> >>
> >> On Tue, Jul 5, 2011 at 3:20 PM, Markus KARG <markus_at_headcrashing.eu>
> >> wrote:
> >> > Because a user might like to configure *all* requests upon a
> resource
> >> > without the need to repeat that with each invocation. If you use
> the
> >> URL
> >> > class, you cannot do that, since the URL class is not
> configurable.
> >> >
> >> >> -----Original Message-----
> >> >> From: guilherme.silveira_at_gmail.com
> >> >> [mailto:guilherme.silveira_at_gmail.com] On Behalf Of Guilherme
> >> Silveira
> >> >> Sent: Dienstag, 5. Juli 2011 20:15
> >> >> To: jsr339-experts_at_jax-rs-spec.java.net
> >> >> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
> >> >>
> >> >> > A resource is something that you can point to using a URL.
> >> >> So I really didnt get why the three interfaces dont solve the
> >> problem
> >> >> as the code I posted.
> >> >>
> >> >> Regards
> >> >>
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: guilherme.silveira_at_gmail.com
> >> >> >> [mailto:guilherme.silveira_at_gmail.com] On Behalf Of Guilherme
> >> >> Silveira
> >> >> >> Sent: Sonntag, 3. Juli 2011 15:31
> >> >> >> To: jsr339-experts
> >> >> >> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
> >> >> >>
> >> >> >> > One might want to apply different sets of features (like
> >> >> filtering,
> >> >> >> caching,
> >> >> >> > etc.) to one resource.
> >> >> >> It seems I didn't quite understand what is being called a
> >> "resource"
> >> >> >> here. Is it something like:
> >> >> >>
> >> >> >> Client client = provider.create();
> >> >> >> Request r = client.at(uri);
> >> >> >> Request first = r.with(filterA()); // this one will only use
> >> filterA
> >> >> >> Request second = r.with(filterB()); // this one will only use
> >> filter
> >> >> B
> >> >> >>
> >> >> >> ?
> >> >> >>
> >> >> >> Regards
> >> >> >>
> >> >> >> Guilherme Silveira
> >> >> >> Caelum | Ensino e Inovação
> >> >> >> http://www.caelum.com.br/
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Sun, Jul 3, 2011 at 10:24 AM, Markus KARG
> >> >> <markus_at_headcrashing.eu>
> >> >> >> wrote:
> >> >> >> > The problem is that three parts does not match all requested
> >> >> >> features:
> >> >> >> >
> >> >> >> > One might want to apply different sets of features (like
> >> >> filtering,
> >> >> >> caching,
> >> >> >> > etc.) to one resource. This information is neither bound to
> the
> >> >> >> client
> >> >> >> > (unless you create one client per resource) nor to the
> request
> >> >> >> (unless you
> >> >> >> > set the configuration at every other request). So to support
> >> this,
> >> >> >> you need
> >> >> >> > the resource as the forth brick in this puzzle. Or you just
> >> will
> >> >> not
> >> >> >> support
> >> >> >> > that usage pattern and prevent the possibily to add it at
> any
> >> >> later
> >> >> >> time, as
> >> >> >> > the API cannot be changed anymore without breaking backwards
> >> >> >> compatibility.
> >> >> >> >
> >> >> >> > Regards
> >> >> >> > Markus
> >> >> >> >
> >> >> >> >> -----Original Message-----
> >> >> >> >> From: guilherme.silveira_at_gmail.com
> >> >> >> >> [mailto:guilherme.silveira_at_gmail.com] On Behalf Of
> Guilherme
> >> >> >> Silveira
> >> >> >> >> Sent: Sonntag, 3. Juli 2011 14:38
> >> >> >> >> To: jsr339-experts
> >> >> >> >> Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
> >> >> >> >>
> >> >> >> >> Hi Markus,
> >> >> >> >>
> >> >> >> >> I can see three distinct elements while requesting:
> >> >> >> >>
> >> >> >> >> :: Provider => Client => Request
> >> >> >> >>
> >> >> >> >> A provider provides a client that starts building a
> request.
> >> The
> >> >> >> >> request builts on top of itself until its dispatched.
> Finally,
> >> on
> >> >> >> the
> >> >> >> >> response:
> >> >> >> >>
> >> >> >> >> :: Response
> >> >> >> >>
> >> >> >> >> I believe this is the simplest I can get. Restfulie is
> >> similar:
> >> >> >> >> Provider = Restfulie
> >> >> >> >> Client = RestClient
> >> >> >> >> Request = Request
> >> >> >> >> Response = Response
> >> >> >> >>
> >> >> >> >> The final code can be any of (explosion of methods or no
> >> compile
> >> >> >> time
> >> >> >> >> check):
> >> >> >> >> Provider.create().at(uri).get()
> >> >> >> >>
> >> >> >> >> or caching objects, with invoke on its parent (apache
> commons
> >> >> alike,
> >> >> >> >> type safe one ntity body etc):
> >> >> >> >> client.invoke(preparedRequest)
> >> >> >> >>
> >> >> >> >> One can break the interface into smaller pieces and try to
> >> >> achieve
> >> >> >> >> better type compile time checking.
> >> >> >> >> I am ignoring the hypermedia part so far (for which I would
> >> add a
> >> >> >> Link
> >> >> >> >> and Form interface).
> >> >> >> >>
> >> >> >> >> Thisis the one I was going to propsoe,but it didnt seem
> >> >> interesting,
> >> >> >> is
> >> >> >> >> it?
> >> >> >> >>
> >> >> >> >> Regards
> >> >> >> >>
> >> >> >> >> Guilherme Silveira
> >> >> >> >> Caelum | Ensino e Inovação
> >> >> >> >> http://www.caelum.com.br/
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Sat, Jul 2, 2011 at 4:56 AM, Markus KARG
> >> >> <markus_at_headcrashing.eu>
> >> >> >> >> wrote:
> >> >> >> >> > Experts,
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > reading the very interesting recent discussion about the
> >> naming
> >> >> of
> >> >> >> >> the
> >> >> >> >> > client parts, I have to say that I share both opinions:
> The
> >> >> >> >> complexity is
> >> >> >> >> > needed to reach the intended feature set and flexibility,
> >> but
> >> >> the
> >> >> >> >> current
> >> >> >> >> > naming is far from being intuitive. Thus, I'd like to
> >> propose
> >> >> just
> >> >> >> >> names
> >> >> >> >> > (not any different implementation or "revolution"). Maybe
> >> >> picking
> >> >> >> >> some of
> >> >> >> >> > them can solve the problem. Maybe other experts have even
> >> >> better
> >> >> >> name
> >> >> >> >> > suggestions to solve the trouble?
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > "Engine", "Implementation", "JAXRS" or "REST" -- The
> major
> >> >> entry
> >> >> >> >> point for
> >> >> >> >> > separating vendor specifics, providing Client. In fact,
> >> >> "Provider"
> >> >> >> is
> >> >> >> >> great
> >> >> >> >> > as it is used by JPA already, it is used already
> differently
> >> in
> >> >> >> JAX-
> >> >> >> >> RS.
> >> >> >> >> > "JAXRS" was inspired by "JAXB", which is a smart, static
> >> entry
> >> >> >> point.
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > "Client" -- A configurable instance ready to access a web
> >> >> resource
> >> >> >> >> (provides
> >> >> >> >> > invocations).
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > "Target" -- sorry but 'Link' is just confusing and
> >> >> "WebResource"
> >> >> >> was
> >> >> >> >> not
> >> >> >> >> > wanted. Also Link might be needed for Hypermedia API
> later
> >> in
> >> >> this
> >> >> >> >> project.
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > "Invocation", "Call", "MethodExecution" -- Well, obvious.
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > I think everybody agrees that the separation is needed,
> so
> >> the
> >> >> >> >> current
> >> >> >> >> > dispute should be easy to solve if more experts share
> their
> >> >> ideas
> >> >> >> >> about the
> >> >> >> >> > naming.
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > About invoke() I understand that it is not smart to need
> >> >> >> >> get().invoke() vs.
> >> >> >> >> > get().queue(), but I do not see that
> >> >> >> invoke(invocationFactory.get())
> >> >> >> >> or
> >> >> >> >> > queue(invocationFactory.get()) would be any better - but
> >> less
> >> >> >> fluent.
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > Regards
> >> >> >> >> >
> >> >> >> >> > Markus
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >