Hi Sergey
No problem!
Guilherme Silveira
On Jul 20, 2011 6:21 PM, "Sergey Beryozkin" <sberyozkin_at_talend.com> wrote:
> Hi Guilherme
>
>
> I saw the code and saw the opportunity to highlight what I saw a problem
> with that approach -
> But sorry for hijacking this thread - I think it happens sometimes :-)
> Sergey
>> Ho Sergey
>>
>> I understand and it makes total sense. In a process you cant expect
>> everything to return what you wanted. Thats why navigatin through remote
>> proxied for rest also seem weird.
>>
>> But is it somehow connected with the question in this thread?
>>
>> regards
>>
>> Guilherme Silveira
>>
>> On Jul 20, 2011 10:46 AM, "Sergey Beryozkin" <sberyozkin_at_talend.com
>> <mailto:sberyozkin_at_talend.com>> wrote:
>> > Hi Guilherme,
>> >> Sure! My bad not to include any example. While writing the example
(see
>> >> below), I realized that the once proposed "Link" type (with its
>> factory)
>> >> would do it, if I am not wrong.
>> >>
>> >> Here is the example:
>> >>
>> >> Take any process that navigates through a set of URIs, as in a process
>> >> that is executed in 4 steps, and you want to execute the same process
>> >> for the 5 different entry points. For example: I want to query
>> different
>> >> providers about some information. So:
>> >>
>> >> client = ...;
>> >> for(entry : entries) {
>> >> result = process1(entry, client.addHeadersForThisRequestA())
>> >> result = process2(result.link("a").addHeadersForThisRequestB())
>> >> result = process3(result.link("b").addHeadersForThisRequestC())
>> >> result = process4(result.link("c").addHeadersForThisRequestD())
>> >> result = process5(result.link("d").addHeadersForThisRequestE())
>> >> }
>> >>
>> >> Every step is based on a link. not an URI. So if the Link type as
>> >> proposed earlier provides the same configuration interface as Resource
>> >> (and the Client), it should be ok.
>> >>
>> >
>> > The above looks nice - but what happens if result.link("a") returns
>> null ?
>> > I'm not trying to be negative here, just think the fluent style works
>> > nice when the builder state is under control, the above is conditional
>> > on the presence of "a", etc.
>> >
>> > Thanks, Sergey
>> >
>> >> Regards
>> >>
>> >> Guilherme Silveira
>> >> Caelum | Ensino e Inovação
>> >> http://www.caelum.com.br/
>> >>
>> >>
>> >> On Thu, Jul 14, 2011 at 2:15 PM, Markus KARG <markus_at_headcrashing.eu
>> <mailto:markus_at_headcrashing.eu>
>> >> <mailto:markus_at_headcrashing.eu <mailto:markus_at_headcrashing.eu>>>
wrote:
>> >>
>> >> Can you give a real-world scenario when something complex like that
>> >> will be
>> >> needed?
>> >>
>> >> > -----Original Message-----
>> >> > From: guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>
>> >> <mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>>
>> >> > [mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>
>> >> <mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>>] On Behalf Of Guilherme Silveira
>> >> > Sent: Mittwoch, 13. Juli 2011 14:24
>> >> > To: jsr339-experts_at_jax-rs-spec.java.net
>> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
>> >> <mailto:jsr339-experts_at_jax-rs-spec.java.net
>> <mailto:jsr339-experts_at_jax-rs-spec.java.net>>
>> >> > Subject: [jsr339-experts] Re: [ClientAPI] Naming Proposals
>> >> >
>> >> > > 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 <mailto:markus_at_headcrashing.eu>
>> <mailto:markus_at_headcrashing.eu <mailto: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>
>> >> <mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>>
>> >> > >> [mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>
>> >> <mailto: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
>> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
>> >> <mailto:jsr339-experts_at_jax-rs-spec.java.net
>> <mailto: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 <mailto:markus_at_headcrashing.eu>
>> <mailto:markus_at_headcrashing.eu <mailto: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>
>> >> <mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>>
>> >> > >> >> [mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>
>> >> <mailto: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
>> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
>> >> <mailto:jsr339-experts_at_jax-rs-spec.java.net
>> <mailto: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 <mailto:markus_at_headcrashing.eu>
>> <mailto:markus_at_headcrashing.eu <mailto: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>
>> >> <mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>>
>> >> > >> >> >> [mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>
>> >> <mailto: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
>> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
>> >> <mailto:jsr339-experts_at_jax-rs-spec.java.net
>> <mailto: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>
>> >> <mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>>
>> >> > >> >> >> >> [mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>
>> >> <mailto: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 <http://client.at>
>> <http://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 <mailto:markus_at_headcrashing.eu>
>> <mailto:markus_at_headcrashing.eu <mailto: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>
>> >> <mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>>
>> >> > >> >> >> >> >> [mailto:guilherme.silveira_at_gmail.com
>> <mailto:guilherme.silveira_at_gmail.com>
>> >> <mailto: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 <mailto:markus_at_headcrashing.eu>
>> <mailto:markus_at_headcrashing.eu <mailto: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
>> >> > >> >> >> >> >> >
>> >> > >> >> >> >> >> >
>> >> > >> >> >> >> >
>> >> > >> >> >> >> >
>> >> > >> >> >> >
>> >> > >> >> >> >
>> >> > >> >> >
>> >> > >> >> >
>> >> > >> >
>> >> > >> >
>> >> > >
>> >> > >
>> >>
>> >>
>> >
>> >
>
>
>