[Pharo-project] Zinc/Zodiac Documentation
Hi, Now that I have recovered from the intensive Pharo Conference, I found the time to publish the Zinc and Zodiac documentation. The two main websites have been updated: http://zn.stfx.eu http://zdc.stfx.eu My slides are here http://zn.stfx.eu/zn/zn-talk-pharo-conference.pdf http://zdc.stfx.eu/zdc-talk-pharo-conference.pdf The documentation (as Pharo Conference paper and draft chapter for Pharo By Example 2) are here http://zn.stfx.eu/zn/zinc-http-components-paper.html http://zdc.stfx.eu/zodiac-paper.html For some inexplicable reason, Google Chrome is extremely slow doing the syntax highlighting on the long Zn paper/chapter, so here is an alternative version http://zn.stfx.eu/zn/zinc-http-components-paper.no-js.html Enjoy! Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
thanks Sven. I have nearly finish to read the zinc chapter. Great contents. I would like to create diagram and others for the book version but no time right now. Stef On May 27, 2012, at 7:34 PM, Sven Van Caekenberghe wrote:
Hi,
Now that I have recovered from the intensive Pharo Conference, I found the time to publish the Zinc and Zodiac documentation.
The two main websites have been updated:
http://zn.stfx.eu http://zdc.stfx.eu
My slides are here
http://zn.stfx.eu/zn/zn-talk-pharo-conference.pdf http://zdc.stfx.eu/zdc-talk-pharo-conference.pdf
The documentation (as Pharo Conference paper and draft chapter for Pharo By Example 2) are here
http://zn.stfx.eu/zn/zinc-http-components-paper.html http://zdc.stfx.eu/zodiac-paper.html
For some inexplicable reason, Google Chrome is extremely slow doing the syntax highlighting on the long Zn paper/chapter, so here is an alternative version
http://zn.stfx.eu/zn/zinc-http-components-paper.no-js.html
Enjoy!
Sven
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
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 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 - I think it should return self, like enforceHttpSuccess:. Besides consistency, it will avoid having to send #yourself when configuring a new client instance. * JSJsonParser - where does this class live? A reference would be great... * 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? * [up/down]load convenience methods - What do you think about adding e.g. ZnEasy>>download:to: & upload:to: (is POST a good default?) -- View this message in context: http://forum.world.st/Zinc-Zodiac-Documentation-tp4632114p4632508.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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
On 30 May 2012, at 18: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
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 - I think it should return self, like enforceHttpSuccess:. Besides consistency, it will avoid having to send #yourself when configuring a new client instance. * JSJsonParser - where does this class live? A reference would be greatâ¦
Hi Sean, I don't know if this is the done thing but I've extracted JSJsonParser from Javascript-Core and removed the dependencies on Seaside and Grease so it loads cleanly into Pharo 1.4 and Pharo 2.0a (and probably 1.3 etc). I'm also planning to write some tests for it but haven't yet. If there's any interest I'd happily push this somewhere :). All the best, Mark
* 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? * [up/down]load convenience methods - What do you think about adding e.g. ZnEasy>>download:to: & upload:to: (is POST a good default?)
-- View this message in context: http://forum.world.st/Zinc-Zodiac-Documentation-tp4632114p4632508.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Sven, First of all congratulation for your work. It is really good. Having ported Swazoo to Dolphin I can figure what it takes to create a whole new HTTP server/client, so again, kudos to you. Regarding the docs, I would switch the links, leaving the no-js option as the default. That will avoid having to cancel the request and reading there is an issue with Chrome. Here it doesn't work neither in Chrome nor Chrome Canary (Win 7 Pro). I look forward to start developing in Pharo again for personal pet-projects, meanwhile I still earn my wage by working with Dolphin, and lately building HTTP API's on it with Swazoo. One of the things that got my attention was how/why you implemented the ServerDelegates. I would really appreciatie if you want to share with me/us what was the rationale behind them in comparison with the "alternative" SwazooResources. Pros and cons, and so on. I found the SwazooResources pretty neat to work with, even to implement special lookups by double dispatching through the URIResolution class. Best regards, -- Esteban -- View this message in context: http://forum.world.st/Zinc-Zodiac-Documentation-tp4632114p4632530.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Esteban, On 30 May 2012, at 20:25, Esteban A. Maringolo wrote:
Sven,
First of all congratulation for your work. It is really good.
Thx.
Having ported Swazoo to Dolphin I can figure what it takes to create a whole new HTTP server/client, so again, kudos to you.
Regarding the docs, I would switch the links, leaving the no-js option as the default. That will avoid having to cancel the request and reading there is an issue with Chrome. Here it doesn't work neither in Chrome nor Chrome Canary (Win 7 Pro).
I look forward to start developing in Pharo again for personal pet-projects, meanwhile I still earn my wage by working with Dolphin, and lately building HTTP API's on it with Swazoo.
One of the things that got my attention was how/why you implemented the ServerDelegates. I would really appreciatie if you want to share with me/us what was the rationale behind them in comparison with the "alternative" SwazooResources. Pros and cons, and so on.
I found the SwazooResources pretty neat to work with, even to implement special lookups by double dispatching through the URIResolution class.
Best regards,
-- Esteban
I did not really think a lot about it: I choose the simplest concept that could work. I guess, from the name and a quick google, that SwazooResource also implies dispatching/routing ? I wanted to avoid that, hence the choice for the delegate concept. I think that something along the lines of SwazooResources could be implemented as a delegate, an extension to Zn. Regards, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
participants (5)
-
Esteban A. Maringolo -
Mark Smith -
Sean P. DeNigris -
Stéphane Ducasse -
Sven Van Caekenberghe