> Am 12.06.2015 um 12:03 schrieb PBKResearch <pe...@pbkresearch.co.uk>: > > Norbert > > Some comments on your latest post below. > > I just wrote because you told Jimmie to alter a method of a third-party > library. And that is a no-go. > > Zinc, like almost all of Pharo, is MIT licenced, “including without > limitation the rights to use, copy, modify, merge, publish…” Once the code is > on my machine, I am entitled to alter it for my own use in any way I see fit; > so is Jimmie. It is clear from Sven’s comments that not encoding commas is a > design decision, and a departure from earlier Zinc working. Sven himself says > “ maybe we made a mistake, maybe not.” I am entitled to disagree with that > decision, and to act on that disagreement; so is Jimmie. I just told him how > to do it quickly and safely. > So, the misunderstanding is because we seem to have different views on the topic. I have always projects in mind that are built together by a build system and they produce something deployable. Your proposal doesn't fit in this view for me. If you alter a third-party function you need to make that a repeatable task which is having an expression to patch the third-party library again if you build the project again.
> The way to change it and have Sven it commited is doable. > > Obviously it would be ideal if Sven made a change which allowed encoding of > commas. However, that does not seem likely to happen any time soon. > Meanwhile, Jimmie was stuck with a program which would not carry out a > function that should be quite normal. > > As is my proposal that you can change the code in a reliable way without > changing a third-party library. That's all I wanted to say. > > No doubt your subclassing approach would work, though not as easily as you > imply. The method that encodes the key-value pairs of a query is not > #encodeQuery:on:, it is #printQueryOn: (see > ZnUrl>>#printPathQueryFragmentOn:); changing that would involve having > variant versions of ZnResourceMetaUtils>>#writeQueryFields:on: and > >>writeQueryFields:withEncoder:on:, as well as a new safe list. Yes, but it is still the thing you can do immediately without having to patch code that is not under your control. That's my whole point. I wouldn't consider my approach good or even nice. > > And yes I think it applies to monkey patching. Choosing weaker terms just to > avoid problems is not the way to go IMHO. > > I was not asking for a weaker term, I was asking for a less offensive one. I > think this term is offensive in all contexts, and should not be used. Henry’s > comment implies that it is widely used, and everyone knows what it means. In > my youth, 60-70 years ago, the n-word was widely used to refer to people of > African origin, and everyone knew what it meant. Now, thank goodness, we see > how offensive it was. To me, this expression is equally offensive. You used > it, in a derogatory sense, to criticise what I had done in helping Jimmie. > Frankly, I do not think you were sincere in saying “No offense meant.” > I like the term monkey patching because it is as funny as it might be offensive. The rest I don't want to comment because I could easily be offended by your paragraph above…if I only had those kinds of sensitivities. And btw. don't hide behind something like not using a certain word. You can still be a racist without using the n-word. What is needed is to change attitude not words. > I had thought of just ignoring your comment, thinking that we will have to > agree to differ. However, your reiteration of the m-word has got me > sufficiently riled to make another protest. I may be a lone voice here, but > that does not make my views any less valid. dito. Let's close this case. To me it is a little misunderstanding that took the wrong route. Norbert > > Peter Kenny > > > From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org] On Behalf Of > Norbert Hartl > Sent: 11 June 2015 17:07 > To: Pharo users users > Subject: Re: [Pharo-users] ZnClient and percent characters > > >> Am 11.06.2015 um 16:51 schrieb PBKResearch <pe...@pbkresearch.co.uk >> <mailto:pe...@pbkresearch.co.uk>>: >> >> Norbert >> >> Apology accepted – I had never heard this term before. However, having read >> the Wikipedia article Henry mentioned, I do not think it applies to what I >> had done. If Sven accepts the argument that commas should always be encoded >> in query lines – and I can see a strong argument for that from what I have >> read – then the change I made is just what he will need to do. I simply >> anticipated the decision. If it goes the other way, then it was just a hack >> to solve Jimmie’s problem – but it might be better to say ‘hack’ rather than >> use a term which is potentially offensive. >> > I just wrote because you told Jimmie to alter a method of a third-party > library. And that is a no-go. The way to change it and have Sven it commited > is doable. As is my proposal that you can change the code in a reliable way > without changing a third-party library. That's all I wanted to say. And yes I > think it applies to monkey patching. Choosing weaker terms just to avoid > problems is not the way to go IMHO. > > >> I also note Jimmie’s argument that, as long as there are some sites which >> insist on encoded commas, it must be possible to generate such lines if Zinc >> is to be generally useful. Whether this should be a user-controlled option, >> as Sven seems to suggest, is open to discussion – but if so I would argue >> for encoding of commas as the safe default, which can be overridden if >> necessary. >> > Sure. Zinc should behave correctly and it should provide functionalities to > make it "less correct". And these functionalities shouldn't be too easy to > use ;) > > Norbert > > >> Peter Kenny >> >> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org >> <mailto:pharo-users-boun...@lists.pharo.org>] On Behalf Of Norbert Hartl >> Sent: 11 June 2015 11:25 >> To: Pharo users users >> Subject: Re: [Pharo-users] ZnClient and percent characters >> >> No offense meant. I assumed you would know the term. Sorry! Henry explained >> it quite good what I meant. >> >> Norbert >> >>> Am 11.06.2015 um 09:51 schrieb PBKResearch <pe...@pbkresearch.co.uk >>> <mailto:pe...@pbkresearch.co.uk>>: >>> >>> I don’t quite understand Norbert’s comment. Does ‘monkey’ apply to me or to >>> what I have done? Either way, it seems unnecessary and abusive. >>> >>> Thanks to Sven’s careful use of informative method names, the effect of my >>> change is quite clear. Any comma in the value part of a query line will be >>> encoded. Nothing else. I did my best to trace any side effects, and didn’t >>> find any. What is not ‘reliable’ about that? >>> >>> Peter Kenny >>> >>> >>> I was thinking of a reliable solution. Of course if it only needs to be >>> tested than monkey patching foreign packages is ok. >>> >>> Norbert >>> >>>> Am 11.06.2015 um 01:22 schrieb PBKResearch <pe...@pbkresearch.co.uk >>>> <mailto:pe...@pbkresearch.co.uk>>: >>>> >>>> There is a simpler way than Norbert’s suggestion. Find the class >>>> ZnResourceMetaUtils (in the package Zinc-Resource-Meta-Core). Locate the >>>> class side method #queryKeyValueSafeSet. Remove the comma from the string. >>>> With this change your ‘Google’ example generates the query line with the >>>> ‘%2C’ encoding of the commas. >>>> >>>> Of course, with this change a comma in the value field of a query will >>>> always be encoded. It is not clear to me whether this is correcting an >>>> error in Zinc, or just a hack to solve your problem – earlier posts here >>>> endorse both views. No doubt Sven is the person to sort this out. >>>> Meanwhile, this will enable you to get moving. >>>> >>>> Hope this helps >>>> >>>> Peter Kenny >>>> >>>> From: Pharo-users [mailto:pharo-users-boun...@lists.pharo.org >>>> <mailto:pharo-users-boun...@lists.pharo.org>] On Behalf Of Norbert Hartl >>>> Sent: 10 June 2015 23:56 >>>> To: Pharo users users >>>> Subject: Re: [Pharo-users] ZnClient and percent characters >>>> >>>> Just to clarify: >>>> >>>> "Characters in the "reserved" set are not reserved in all contexts. >>>> The set of characters actually reserved within any given URI >>>> component is defined by that component. In general, a character is >>>> reserved if the semantics of the URI changes if the character is >>>> replaced with its escaped US-ASCII encoding." >>>> If I were you I'd subclass ZnUrl and implement >>>> #encodeQuery:on: >>>> on that class. You could have an extension method in ZnResourceMetaUtils >>>> that returns the character set you need to have encoded. In ZnClient you >>>> just set your ZnUrl derived class object as #url: >>>> Cannot think of anything better for a quick resolve of your problem. >>>> Norbert >>>>> Am 11.06.2015 um 00:26 schrieb Jimmie Houchin <jlhouc...@gmail.com >>>>> <mailto:jlhouc...@gmail.com>>: >>>>> >>>>> I am not an expert on URIs or encoding. However, this is a requirement of >>>>> the API I am using and I am required to submit an encoded URI with %2C >>>>> and no commas. >>>>> >>>>> As far as commas needing to be escaped, it seems from other sources that >>>>> they should be. >>>>> >>>>> From https://www.ietf.org/rfc/rfc2396.txt >>>>> <https://www.ietf.org/rfc/rfc2396.txt> >>>>> >>>>> >>>>> >>>>> >>>>> The plus "+", dollar "$", and comma "," characters have been added to >>>>> those in the "reserved" set, since they are treated as reserved >>>>> within the query component. >>>>> >>>>> States that commas are reserved within the query component. >>>>> >>>>> http://stackoverflow.com/questions/8828702/why-is-the-comma-url-encoded >>>>> <http://stackoverflow.com/questions/8828702/why-is-the-comma-url-encoded> >>>>> >>>>> Regardless of what is or is not required, I do need the ability to have a >>>>> query string with commas encoded as %2C in order to satisfy and use the >>>>> API which states. >>>>> >>>>> fields: Optional An URL encoded (%2C) comma separated list of instrument >>>>> fields that are to be returned in the response. The instrument field will >>>>> be returned regardless of the input to this query parameter. Please see >>>>> the Response Parameters section below for a list of valid values. >>>>> >>>>> Which will look like this or something similar. >>>>> >>>>> fields=displayName%2Cinstrument%2Cpip >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> Jimmie >>>>> >>>>> On 06/10/2015 03:27 PM, Norbert Hartl wrote: >>>>>> That's because the comma does not need to be escaped in the query part >>>>>> of the uri. >>>>>> >>>>>> Norbert >>>>>> >>>>>>> Am 10.06.2015 um 22:00 schrieb Jimmie Houchin <jlhouc...@gmail.com> >>>>>>> <mailto:jlhouc...@gmail.com>: >>>>>>> >>>>>>> On 06/10/2015 10:32 AM, Sven Van Caekenberghe wrote: >>>>>>>>> On 10 Jun 2015, at 17:24, David <stormb...@gmail.com> >>>>>>>>> <mailto:stormb...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> El Wed, 10 Jun 2015 10:14:37 -0500 >>>>>>>>> Jimmie Houchin <jlhouc...@gmail.com> <mailto:jlhouc...@gmail.com> >>>>>>>>> escribió: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I am attempting to use ZnClient to request data. The request requires >>>>>>>>>> a %2C (comma) delimited string as part of the query. Below is a >>>>>>>>>> snippet. >>>>>>>>>> >>>>>>>>>> znClient >>>>>>>>>> addPath: '/v1/instruments'; >>>>>>>>>> queryAt: 'fields' putAll: 'displayName%2Cinstrument%2Cpip'; >>>>>>>>>> get ; >>>>>>>>>> contents) >>>>>>>>>> >>>>>>>>>> The string 'displayName%2Cinstrument%2Cpip' >>>>>>>>>> is being converted to 'displayName%252Cinstrument%252Cpip' >>>>>>>>>> which causes the request to fail. >>>>>>>>>> >>>>>>>>>> The query needs to be >>>>>>>>>> fields=displayName%2Cinstrument%2Cpip >>>>>>>>>> >>>>>>>>>> I have not found how to do this correctly. >>>>>>>>>> Any help greatly appreciated. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> Jimmie >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Maybe a silly thing, but since %2C = , ... Did you tried already to >>>>>>>>> make itself encode that? Like >>>>>>>>> znClient >>>>>>>>> addPath: '/v1/instruments'; >>>>>>>>> queryAt: 'fields' putAll: 'displayName,instrument,pip'; >>>>>>>>> get ; >>>>>>>>> contents) >>>>>>>>> >>>>>>>>> I suspect it is using encoding internally, that is why % is also >>>>>>>>> encoded if you try to put it. >>>>>>>>> >>>>>>>>> I hope that works >>>>>>>> Not silly and no need to suspect, but absolutely correct ! >>>>>>>> >>>>>>>> Sven >>>>>>> My apologies for not having full disclosure. >>>>>>> >>>>>>> Pharo 4, new image, freshly installed Zinc stable version. >>>>>>> Xubuntu 15.04 >>>>>>> >>>>>>> >>>>>>> >>>>>>> That is what I thought would happen and what I tried first. But it is >>>>>>> not being encoded from what I can find. >>>>>>> >>>>>>> Inspect this in a workspace/playground. >>>>>>> >>>>>>> ZnClient new >>>>>>> https; >>>>>>> host: 'google.com <http://google.com/>'; >>>>>>> addPath: '/commaTest'; >>>>>>> queryAt: 'fields' put: 'displayName,instrument,pip'; >>>>>>> yourself >>>>>>> >>>>>>> View the request / requestLine / uri. The commas are still present in >>>>>>> the URI. >>>>>>> So I tried encoding myself and get the other error. >>>>>>> >>>>>>> Of course Google won't understand this and in this snippet won't >>>>>>> receive it. >>>>>>> >>>>>>> And please let me know if I am doing something wrong. >>>>>>> >>>>>>> Any help greatly appreciated. >>>>>>> >>>>>>> Jimmie
