> 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
>> >> >
>> >> >
>> >
>> >
>
>