> I do not see a need for that.
And if the client needs to set 3 config for N resources, but not for
every resource, he will do:
Resource 1st = ...
Resource 2nd = ...
...
Resource nth = ...
config(1st, 2nd, ... nth);
void config(List<Resource> rs) {
for(Resource r:rs) {
r.enableFeature(first);
r.enableFeature(second);
r.withHeaders...;
}
}
Something like that?
Regards
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Tue, Jul 12, 2011 at 2:57 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
> 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
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>
>