Sean, On 30 May 2012, at 19:06, Sean P. DeNigris wrote:
> Sven Van Caekenberghe wrote >> Now that I have recovered from the intensive Pharo Conference, I found the >> time to publish the Zinc and Zodiac documentation. >> ... >> http://zn.stfx.eu/zn/zinc-http-components-paper.html >> http://zdc.stfx.eu/zodiac-paper.html > > Wow, really clear and thorough. The way the raw internet protocols are woven > into the examples is really cool (I always have to be reminded that there's > no magic, just binary turtles all the way down)… And I found > numberOfRetries:, retryDelay:, contentReader:, and #enforceHttpSuccess: > particularly useful in simplifying my code I am glad it is useful to you. > A few thoughts: > * ZnClient>>retryDelay: > - it'd be nice if it took aDuration. If I was reading someone else's code, > "client retryDelay: 30" forces me to find the method, but "client > retryDelay: 30 seconds" is clear Yeah, I thought about that too, and I guess at one point I decided to go for seconds as an integer. Note that apart from #retryDelay:, there are also #timeout: and #connectionReuseTimeout:. I think I did that because SocketStream uses seconds as timeout value too. Now I will think about changing that, it feels nicer with Durations. > - I think it should return self, like enforceHttpSuccess:. Besides > consistency, it will avoid having to send #yourself when configuring a new > client instance. You are right (copy/paste coding from the getters). ==================== Summary ==================== Name: Zinc-HTTP-SvenVanCaekenberghe.280 Author: SvenVanCaekenberghe Time: 30 May 2012, 10:14:53 pm UUID: 00d1da5e-18a2-4f96-afe7-c7f7d6fe0c6c Ancestors: Zinc-HTTP-SvenVanCaekenberghe.279 clean up ZnClient option setter methods to return self for easy chaining (thx Sean DeNigris) > * JSJsonParser - where does this class live? A reference would be great… It is in Seaside ;-) > * FileSystem - I remember you mentioned having a problem with FS. Has this > been solved? There is a slice in the inbox which replaces all uases of > FileDirectory and friends with FS. Also, how will this effect portability > (e.g. to Squeak). If you make Zn depend on FS, is the Pharo (renamed > classes) version of FS loadable in Squeak trunk? Yes, that will be a challenge ;-) I guess it won't work without a simple compatibility layer. > * [up/down]load convenience methods - What do you think about adding e.g. > ZnEasy>>download:to: & upload:to: (is POST a good default?) Hmm. the goal is not to push ZnEasy too much. I'll consider it. Thanks for the feedback, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
