- Pharo-users - lists.pharo.org

Three copies of JSON-ul.35 on Smalltalkhub

by Paul DeBruicker

There are (at least) three locations of the JSON-ul.35 package on Smalltalkhub. Here: http://smalltalkhub.com/#!/~NicolasPetton/JSON/ here: http://smalltalkhub.com/#!/~PharoExtras/JSON/ and here: http://smalltalkhub.com/#!/~pdebruic/JSONg I've also unknowingly duplicated Stef's efforts at making a ConfigurationOfJSON again here: http://smalltalkhub.com/#!/~pdebruic/JSONg (but this version includes the JSON port to Gemstone) Which of the above should we treat as the canonical JSON repository? Thanks Paul

Oct. 23, 2013

Re: [Pharo-users] add me to the PharoExtras/Postmark repo?

by StÃ©phane Ducasse

done Let me know if this is ok for you. I migrated that code from ss3 or ss. Stef On Oct 23, 2013, at 12:23 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Hi Stef, > > this one: > > http://smalltalkhub.com/#!/~PharoExtras/Postmark/ > > I want to implement their email parsing api sometime soonish > > Thanks > > Paul > >

Oct. 23, 2013

Re: [Pharo-users] add me to the PharoExtras/Postmark repo?

by Marcus Denker

On Oct 23, 2013, at 2:59 AM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > Hi Stef, > > this one: > > http://smalltalkhub.com/#!/~PharoExtras/Postmark/ > > I want to implement their email parsing api sometime soonish > Very nice! Postmark is really a nice way to send email from Pharo. We are using it in the ESUG registration app and it works perfectly. Marcus

Oct. 23, 2013

add me to the PharoExtras/Postmark repo?

by Paul DeBruicker

Hi Stef, this one: http://smalltalkhub.com/#!/~PharoExtras/Postmark/ I want to implement their email parsing api sometime soonish Thanks Paul

Oct. 22, 2013

Re: [Pharo-users] Zinc: How to use the @ character in an URL

by Sven Van Caekenberghe

On 22 Oct 2013, at 22:26, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > BTW, I like the way you code clients and am learning a hefty bit from your damn great code :-) > > And I mean it. Thanks!

Oct. 22, 2013

Re: [Pharo-users] Zinc: How to use the @ character in an URL

by phil＠highoctane.be

BTW, I like the way you code clients and am learning a hefty bit from your damn great code :-) And I mean it.

Oct. 22, 2013

Re: [Pharo-users] Zinc: How to use the @ character in an URL

by Sven Van Caekenberghe

On 22 Oct 2013, at 18:27, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > Ok, point taken. > > Still, ZnClient is unusable for the intended purpose as is. No matter what encoding, % or not, Olivier cannot get the URL to work. Couldn't the ZnClient use something like the StampClient does: options? (where prefetch-count can be set for example - I also discovered the little inbox thing after some hair pulling sessions BTW). > > > Phil But Olivier's problem is that he is talking to a server that does not do proper percent decoding, IMHO. A server parsing a URL should resolve all percent encodings, after parsing using the significant delimiters (/ : ? #). http://foo.com/abc and http://foo.com/%61%62%63 are the same thing, just like http://foo.com/abc@1 and http://foo.com/abc%401 are - again as far as I understand it. That being said, I am going to study the specs again and might change what gets encoded or not depending on the URL element, instead of encoding aggressively in the better safe than sorry way. Olivier's suggestion about safer authorisation parsing does make sense and will get added as well - Thanks Olivier ! Sven PS: BTW, ZnClient has such an option object already.

Oct. 22, 2013

Re: [Pharo-users] Zinc: How to use the @ character in an URL

by phil＠highoctane.be

Ok, point taken. Still, ZnClient is unusable for the intended purpose as is. No matter what encoding, % or not, Olivier cannot get the URL to work. Couldn't the ZnClient use something like the StampClient does: options? (where prefetch-count can be set for example - I also discovered the little inbox thing after some hair pulling sessions BTW). Phil

Oct. 22, 2013

Re: [Pharo-users] Zinc: How to use the @ character in an URL

by Sven Van Caekenberghe

On 22 Oct 2013, at 16:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 22 Oct 2013, at 15:49, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > >> I'd say you can encode @ with % in the URL (but it is not needed in any case) indeed but in the rendered output? (Do you mean in hrefs="xxx" ?) >> >> Some things must be encoded indeed: >> >> http://en.wikipedia.org/wiki/Character_entity_reference >> http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_referenc… >> http://www.w3schools.com/tags/ref_urlencode.asp >> >> As '@' is in the ASCII set, why should it be encoded? > > Because that is what the spec says: > > http://en.wikipedia.org/wiki/Percent-encoding#Types_of_URI_characters > > These characters, > > ! * ' ( ) ; : @ & = + $ , / ? # [ ] > > have to be percent encoded in external (printed) representations of URLs, ASCII or not. > > This has nothing to do with HTML or XML. > > ZnPercentEncoder uses the following > > A B C D E F G H I J K L M N O P Q R S T U V W X Y Z > a b c d e f g h i j k l m n o p q r s t u v w x y z > 0 1 2 3 4 5 6 7 8 9 - _ . ~ > > as its safe set (characters that do not have to be encoded), just like the spec says. > > I could be wrong, but I don't think so. Well, the finer point is of course <quote> When a character from the reserved set (a "reserved character") has special meaning (a "reserved purpose") in a certain context, and a URI scheme says that it is necessary to use that character for some other purpose, then the character must be percent-encoded. </quote> and <quote> Reserved characters that have no reserved purpose in a particular context may also be percent-encoded but are not semantically different from those that are not. In the "query" component of a URI (the part after a ? character), for example, "/" is still considered a reserved character but it normally has no reserved purpose, unless a particular URI scheme says otherwise. The character does not need to be percent-encoded when it has no reserved purpose. </quote> So in each context (scheme, url part) it might be slightly different. ZnPercentEncoder takes the better safe than sorry route. > Sven > >> URL Encoding of @ is %40 indeed but digits also have encodings. Not a reason to use them :-) >> >> >> I'd say that the issue is in ZnClient, basically defaulting to a capability that is linked to server interpretation of URLs. >> There is no reason why the URL you use must be associated with authentication, only that mainstream servers can do that with mod_auth or something. >> >> Other than that it is just a pathinfo string. >> >> A ZnClient option saying 'enableAuthority:' maybe? I do not think that a better parsing of options would solve the situation as someone may want to have the same scheme but for other purposes. >> >> Phil >

Oct. 22, 2013

Re: [Pharo-users] Zinc: How to use the @ character in an URL

by Sven Van Caekenberghe

On 22 Oct 2013, at 15:49, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: > I'd say you can encode @ with % in the URL (but it is not needed in any case) indeed but in the rendered output? (Do you mean in hrefs="xxx" ?) > > Some things must be encoded indeed: > > http://en.wikipedia.org/wiki/Character_entity_reference > http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_referenc… > http://www.w3schools.com/tags/ref_urlencode.asp > > As '@' is in the ASCII set, why should it be encoded? Because that is what the spec says: http://en.wikipedia.org/wiki/Percent-encoding#Types_of_URI_characters These characters, ! * ' ( ) ; : @ & = + $ , / ? # [ ] have to be percent encoded in external (printed) representations of URLs, ASCII or not. This has nothing to do with HTML or XML. ZnPercentEncoder uses the following A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 - _ . ~ as its safe set (characters that do not have to be encoded), just like the spec says. I could be wrong, but I don't think so. Sven > URL Encoding of @ is %40 indeed but digits also have encodings. Not a reason to use them :-) > > > I'd say that the issue is in ZnClient, basically defaulting to a capability that is linked to server interpretation of URLs. > There is no reason why the URL you use must be associated with authentication, only that mainstream servers can do that with mod_auth or something. > > Other than that it is just a pathinfo string. > > A ZnClient option saying 'enableAuthority:' maybe? I do not think that a better parsing of options would solve the situation as someone may want to have the same scheme but for other purposes. > > Phil

Oct. 22, 2013