On 02/09/11 12:32, Marek Potociar wrote:
>
>
> On 09/02/2011 12:38 PM, Sergey Beryozkin wrote:
>> On 02/09/11 10:41, Marek Potociar wrote:
>>>
>>>
>>> On 09/01/2011 07:33 PM, Sergey Beryozkin wrote:
>>>> On 01/09/11 15:34, Marek Potociar wrote:
>>>>> Not sure I understand what is supposed to be over-engineered here. Different (sub)resources may have different
>>>>> requirements. These requirements may be represented as different set of target configurations. Sometimes the different
>>>>> requirements may be even at the level of a single request - e.g. you need to be authenticated to do PUT or POST, but
>>>>> you
>>>>> can freely invoke a safe operation, such as GET. It's common use case with many existing web pages, including java.net.
>>>>
>>>> I can see how the idea in general, disagree it's practical to assume the immutability of URI is needed to address
>>>> "Sometimes the different requirements may be even at the level of a single request" because it's difficult to imagine a
>>>> case when a *single" mutable Target URI instance is shared between multiple concurrent consumers all having diff auth
>>>> requirements. Even it's feasible, it does not warrant in itself the need for the immutability given how highly
>>>> 'esoteric' this case is IMHO.
>>>
>>> This is not about concurrency, this is about demarcating the configuration boundaries. Different URIs point to different
>>> resources. Different resources may have different configuration requirements. Concurrency has nothing to do with it.
>>
>> I may've got it wrong, as far as the concurrency is concerned. I think though a practical code would not rely on the
>> config demarcation facilitated by the Target's immutability:
>>
>> right, I'm here now, so lets apply this filter, now move next, hmm, may be I should apply another filter here, actually,
>> what user I am, is it POST or PUT or GET ? That sounds highly unpractical to me - I'd think how to do it at the
>> practical level without expecting the mainline code to *know* it all and not building this into API.
>>
>> May be I'm just missing the point.
>
> I don't know how to make it more clear at the moment. I think that in the course of our discussion I did cover all the
> various aspect of why Target is designed immutable wrt. URI. Configuration is one aspect of it, but you need to look at
> it from the higher-level perspective taking into account all parts of the story and look beyond a simple single-request
> use case.
I haven't asked for clarifications this time. I've expressed my
reservations about the practicality - it's up to you how to react to it...
>
>>>
>>> Additionally, current design proves practical for traversing URI hierarchies, as shown by the iteration examples earlier.
>>>
>> Yes I can agree - you can't use a Target to glide back and forward, be a bit more 'capable' but may be it's a bit
>> hypothetical...
>
> Not sure I understand. It was you who came with the example where you wanted to move back and forth in the resource
> hierarchy. Why are you now saying it's all hypothetical?
>
Sorry, chose a wrong word. I actually don't think it is - but given your
resistance to having back(), and in fact, the uselessness of having
back() given that Target is immutable, I chose to resort to saying it
was hypothetical to talk about Target gliding back and forth with the
current revision - hope that makes it clearer
>>> Consider looking at it in the following perspective:
>>>
>>> 1. Target is a link to a particular resource
>>> 2. The invocation above, in terms of resources captures a resource transition:
>>>
>>> client.target("http://bar").path(1).path(2).path(2).path(4)
>>> R1 ----------> R2 ---> R3 ---> R4 ---> R5
>>>
>>> So, the Target.path() tells you "from here, go there", not "change this resource into that resource".
>>>
>> OK. This looks OK. I guess I'm saying that .path(1).path(2).path(2).path(4) does look like a classical builder chain to
>> me and perhaps it might be a bit confusing...Assuming you want to keep the immutability, then may be rename path() to
>> toPath() or next() or forward(), to capture "from here, go there" better.
>
> I just used the names from UriBuilder, since JAX-RS 1.x users should be familiar with those names.
>
UriBuilder is a mutable one, isn't it ? That is what I'm trying to say,
path().path() is associated with the state being mutated - for me at
least. You can have path() unchanged - JavaDocs will be there, but
recall your argument about revert(String, String) :-)
>>
>>> Another example to illustrate that the resources are really different is here - consider which of the following reads
>>> better:
>>>
>>> A)
>>> Target library = Client.target("http://library");
>>> Target books = library.path("books");
>>> Target dantesDivineComedy = books.queryParam("ISBN-13", "978-0451208637");
>>>
>>> B)
>>> Target library = Client.target("http://library");
>>> library = library.path("books");
>>> library = books.queryParam("ISBN-13", "978-0451208637");
>>>
>>> I hope we can agree that A) makes more sense.
>>>
>> A) looks fine, but a bit unusual, when I type a URI in the browser, I'm still working with the same URI string, which I
>> guess B) captures pretty well.
>
> What are you trying to say? We don't work here with strings, we work with resources and their URIs. This is not a text
> editor API.
>
I'm simply giving you my feedback. You cleverly chose the naming of
Target in A) to demo the immutability and yes, the fact we have 3
individual resources there. I said that B) can also be used to reflect
the actual way a user works with the service.
>> A is more naturally readable - but you can't get from the books section back to the
>> library entry. Which is possible with B...
>
> Are you really suggesting, that in the example A, after executing line 2 you cannot refer to the library, but in the
> (corrected) example B you can?? Are we both still talking about Java code? :)
>
I clearly said that you can't move back from
books to library - are you suggesting that is possible ?
Sergey
> Marek
--
Sergey Beryozkin
http://sberyozkin.blogspot.com
Talend - http://www.talend.com