[Pharo-project] [Progress Report] Zinc HTTP Components
This is another progress report on the Zinc HTTP Components project. - I finally integrated support for UTF-8 encoding and decoding of text entities (ZnStringEntity, ZnUTF8Encoder). - Internally, all input and output is done through binary streams (but character streams are still supported for debugging). - A number of units tests were added. - Class comments were improved. - Lots of small fixes and new features. The overall structure of the project was improved by moving old code into a separate MC package, renaming categories and renaming some classes. The external documentation was updated http://homepage.mac.com/svc/Zinc-HTTP-Components I would still love more users/testers. The code works well enough for day to day use and the feature set is reasonably complete now. Sven PS: Please check the SqueakSource history for a all the details.
I scanned the code a few days ago. I tried an initial port to gemstone. There are quite a few things to do. After discovering that there are really big changes from version to version and the existence of classes with suffixes Old and New made me stop the effort. I'm really missing a usable http client in gemstone but it seemed to be very hard to keep up with the port. Do you port an existing library to smalltalk or do you figure out how it should be done right now? And what do you think about going towards cross-platform? This would need a decision if you are willing to integrate grease/sport in your client. I can imagine that this is not wanted per se because it introduces dependencies. It will be just very hard to do it cross-platform if you do not. Norbert On 07.12.2010, at 17:21, Sven Van Caekenberghe wrote:
This is another progress report on the Zinc HTTP Components project.
- I finally integrated support for UTF-8 encoding and decoding of text entities (ZnStringEntity, ZnUTF8Encoder). - Internally, all input and output is done through binary streams (but character streams are still supported for debugging). - A number of units tests were added. - Class comments were improved. - Lots of small fixes and new features.
The overall structure of the project was improved by moving old code into a separate MC package, renaming categories and renaming some classes.
The external documentation was updated
http://homepage.mac.com/svc/Zinc-HTTP-Components
I would still love more users/testers. The code works well enough for day to day use and the feature set is reasonably complete now.
Sven
PS: Please check the SqueakSource history for a all the details.
Norbert, Thanks for you interest. On 07 Dec 2010, at 21:14, Norbert Hartl wrote:
I scanned the code a few days ago. I tried an initial port to gemstone. There are quite a few things to do. After discovering that there are really big changes from version to version and the existence of classes with suffixes Old and New made me stop the effort. I'm really missing a usable http client in gemstone but it seemed to be very hard to keep up with the port.
This should be much better now: the whole confusion is now gone (the 'Old' categories and classes were moved into a separate MC package that should not be loaded unless you want to do historical research; the 'New' has been removed from existing categories). Please have another look. I assume that you have read the overview and getting started pages (http://homepage.mac.com/svc/Zinc-HTTP-Components). The category 'Zinc-HTTP-Core' contains a object model of the key building blocks of the HTTP protocol. Except for learning and teaching, this is not useful on itself. Building on top of the core are the classes in 'Zinc-HTTP-Server' for various clients and servers. The category 'Zinc-HTTP-Support' contains helpers for the implementation, many of which can be considered portability enablers (much like Seaside has them). Now, why is there not just one good client, why are there 4 different ones ? Because different users have different requirements, because each of them has different features, complexity and above all, a different interface. Part of this is also a search for the ideal API. ZnClient is the simplest one: some class methods to fire off one shot requests. ZnFixedClient is useful to connect to a single server and reuse the connection for multiple requests, like with a web services API. ZnHttpClient is a builder like interface (think of Gofer), it also has some extra features. ZnHTTPSocketFacade is a replacement for the current Pharo/Squeak HTTPSocket API. In my development images, this is active, which means that all HTTP functionality (for MC for example) is handled by Zinc HTTP - a case of eating my own dog food. On the server side there is ZnServer which can be customized with a delegate and authorizer. A static web file server, a Monticello server as well as a Seaside adaptor are available.
Do you port an existing library to smalltalk or do you figure out how it should be done right now? And what do you think about going towards cross-platform? This would need a decision if you are willing to integrate grease/sport in your client. I can imagine that this is not wanted per se because it introduces dependencies. It will be just very hard to do it cross-platform if you do not.
The first goal of Zinc HTTP is to be useful for Pharo, to replace existing HTTP functionality in the image. Hence portability is not high on the list. Like you said, building on top of a portability layer would mean external dependencies that would most probably conflict with the first goal. But I am not against portability (most of the code except for some obvious missing crypto stuff still runs on Squeak as well). We can always try to find a solution. Regards, Sven
Very cool framework, I like it a lot! I definitely vote to eventually replace HTTPSocket with Zinc HTTP Components. I wonder why ZnFixedClient is not a subclass of ZnHttpClient? I think it would be cool to be able to use them polymorphic. Lukas On 8 December 2010 09:26, Sven Van Caekenberghe <sven@beta9.be> wrote:
Norbert,
Thanks for you interest.
On 07 Dec 2010, at 21:14, Norbert Hartl wrote:
I scanned the code a few days ago. I tried an initial port to gemstone. There are quite a few things to do. After discovering that there are really big changes from version to version and the existence of classes with suffixes Old and New made me stop the effort. I'm really missing a usable http client in gemstone but it seemed to be very hard to keep up with the port.
This should be much better now: the whole confusion is now gone (the 'Old' categories and classes were moved into a separate MC package that should not be loaded unless you want to do historical research; the 'New' has been removed from existing categories). Please have another look.
I assume that you have read the overview and getting started pages (http://homepage.mac.com/svc/Zinc-HTTP-Components).
The category 'Zinc-HTTP-Core' contains a object model of the key building blocks of the HTTP protocol. Except for learning and teaching, this is not useful on itself. Building on top of the core are the classes in 'Zinc-HTTP-Server' for various clients and servers. The category 'Zinc-HTTP-Support' contains helpers for the implementation, many of which can be considered portability enablers (much like Seaside has them).
Now, why is there not just one good client, why are there 4 different ones ?
Because different users have different requirements, because each of them has different features, complexity and above all, a different interface. Part of this is also a search for the ideal API.
ZnClient is the simplest one: some class methods to fire off one shot requests.
ZnFixedClient is useful to connect to a single server and reuse the connection for multiple requests, like with a web services API.
ZnHttpClient is a builder like interface (think of Gofer), it also has some extra features.
ZnHTTPSocketFacade is a replacement for the current Pharo/Squeak HTTPSocket API. In my development images, this is active, which means that all HTTP functionality (for MC for example) is handled by Zinc HTTP - a case of eating my own dog food.
On the server side there is ZnServer which can be customized with a delegate and authorizer. A static web file server, a Monticello server as well as a Seaside adaptor are available.
Do you port an existing library to smalltalk or do you figure out how it should be done right now? And what do you think about going towards cross-platform? This would need a decision if you are willing to integrate grease/sport in your client. I can imagine that this is not wanted per se because it introduces dependencies. It will be just very hard to do it cross-platform if you do not.
The first goal of Zinc HTTP is to be useful for Pharo, to replace existing HTTP functionality in the image. Hence portability is not high on the list. Like you said, building on top of a portability layer would mean external dependencies that would most probably conflict with the first goal. But I am not against portability (most of the code except for some obvious missing crypto stuff still runs on Squeak as well). We can always try to find a solution.
Regards,
Sven
-- Lukas Renggli www.lukas-renggli.ch
On 08 Dec 2010, at 10:48, Lukas Renggli wrote:
Very cool framework, I like it a lot! I definitely vote to eventually replace HTTPSocket with Zinc HTTP Components.
Thanks a lot, I am glad you like it.
I wonder why ZnFixedClient is not a subclass of ZnHttpClient?
Well, ZnFixedClient is what I wrote earlier for my needs (I use it inside a T3RestJsonClient, then T3CachingRestJsonClient and finally a business specific T3Client, works very well). ZnHttpClient is Matt's later version, partially inspired by your idea of a builder-style API.
I think it would be cool to be able to use them polymorphic.
We could maybe use some refactoring, consolidation, redesign (hint, hint). But for me, it is also a search for good solutions where I don't think that one size will fit all, but I could be wrong (for example, Matt's redirection, cookie and more advanced authoritzation support would be nice to have everywhere, it is just that I did not need it yet in my applications). Sven
On Dec 8, 2010, at 10:48 AM, Lukas Renggli wrote:
Very cool framework, I like it a lot! I definitely vote to eventually replace HTTPSocket with Zinc HTTP Components.
I would love that. We plan to open 1.3 Unstable 1 of january :) So if you have code for that let me know :)
I wonder why ZnFixedClient is not a subclass of ZnHttpClient? I think it would be cool to be able to use them polymorphic.
Lukas
On 8 December 2010 09:26, Sven Van Caekenberghe <sven@beta9.be> wrote:
Norbert,
Thanks for you interest.
On 07 Dec 2010, at 21:14, Norbert Hartl wrote:
I scanned the code a few days ago. I tried an initial port to gemstone. There are quite a few things to do. After discovering that there are really big changes from version to version and the existence of classes with suffixes Old and New made me stop the effort. I'm really missing a usable http client in gemstone but it seemed to be very hard to keep up with the port.
This should be much better now: the whole confusion is now gone (the 'Old' categories and classes were moved into a separate MC package that should not be loaded unless you want to do historical research; the 'New' has been removed from existing categories). Please have another look.
I assume that you have read the overview and getting started pages (http://homepage.mac.com/svc/Zinc-HTTP-Components).
The category 'Zinc-HTTP-Core' contains a object model of the key building blocks of the HTTP protocol. Except for learning and teaching, this is not useful on itself. Building on top of the core are the classes in 'Zinc-HTTP-Server' for various clients and servers. The category 'Zinc-HTTP-Support' contains helpers for the implementation, many of which can be considered portability enablers (much like Seaside has them).
Now, why is there not just one good client, why are there 4 different ones ?
Because different users have different requirements, because each of them has different features, complexity and above all, a different interface. Part of this is also a search for the ideal API.
ZnClient is the simplest one: some class methods to fire off one shot requests.
ZnFixedClient is useful to connect to a single server and reuse the connection for multiple requests, like with a web services API.
ZnHttpClient is a builder like interface (think of Gofer), it also has some extra features.
ZnHTTPSocketFacade is a replacement for the current Pharo/Squeak HTTPSocket API. In my development images, this is active, which means that all HTTP functionality (for MC for example) is handled by Zinc HTTP - a case of eating my own dog food.
On the server side there is ZnServer which can be customized with a delegate and authorizer. A static web file server, a Monticello server as well as a Seaside adaptor are available.
Do you port an existing library to smalltalk or do you figure out how it should be done right now? And what do you think about going towards cross-platform? This would need a decision if you are willing to integrate grease/sport in your client. I can imagine that this is not wanted per se because it introduces dependencies. It will be just very hard to do it cross-platform if you do not.
The first goal of Zinc HTTP is to be useful for Pharo, to replace existing HTTP functionality in the image. Hence portability is not high on the list. Like you said, building on top of a portability layer would mean external dependencies that would most probably conflict with the first goal. But I am not against portability (most of the code except for some obvious missing crypto stuff still runs on Squeak as well). We can always try to find a solution.
Regards,
Sven
-- Lukas Renggli www.lukas-renggli.ch
On 08 Dec 2010, at 15:58, Stéphane Ducasse wrote:
On Dec 8, 2010, at 10:48 AM, Lukas Renggli wrote:
Very cool framework, I like it a lot! I definitely vote to eventually replace HTTPSocket with Zinc HTTP Components.
I would love that. We plan to open 1.3 Unstable 1 of january :) So if you have code for that let me know :)
Date today >= (Date year: 2011 month: 1 day: 1) ifTrue: [ Gofer it squeaksource: 'ZincHTTPComponents'; package: 'Zinc-HTTP'; package: 'Zinc-Tests'; package: 'Zinc-Patch-HTTPSocket'; load ]. ;-) Sven
;)
Very cool framework, I like it a lot! I definitely vote to eventually replace HTTPSocket with Zinc HTTP Components.
I would love that. We plan to open 1.3 Unstable 1 of january :) So if you have code for that let me know :)
Date today >= (Date year: 2011 month: 1 day: 1) ifTrue: [ Gofer it squeaksource: 'ZincHTTPComponents'; package: 'Zinc-HTTP'; package: 'Zinc-Tests'; package: 'Zinc-Patch-HTTPSocket'; load ].
;-)
Sven
On Dec 8, 2010, at 9:26 AM, Sven Van Caekenberghe wrote:
Norbert,
Thanks for you interest.
On 07 Dec 2010, at 21:14, Norbert Hartl wrote:
I scanned the code a few days ago. I tried an initial port to gemstone. There are quite a few things to do. After discovering that there are really big changes from version to version and the existence of classes with suffixes Old and New made me stop the effort. I'm really missing a usable http client in gemstone but it seemed to be very hard to keep up with the port.
This should be much better now: the whole confusion is now gone (the 'Old' categories and classes were moved into a separate MC package that should not be loaded unless you want to do historical research; the 'New' has been removed from existing categories). Please have another look.
I assume that you have read the overview and getting started pages (http://homepage.mac.com/svc/Zinc-HTTP-Components).
The category 'Zinc-HTTP-Core' contains a object model of the key building blocks of the HTTP protocol. Except for learning and teaching, this is not useful on itself. Building on top of the core are the classes in 'Zinc-HTTP-Server' for various clients and servers. The category 'Zinc-HTTP-Support' contains helpers for the implementation, many of which can be considered portability enablers (much like Seaside has them).
Now, why is there not just one good client, why are there 4 different ones ?
Because different users have different requirements, because each of them has different features, complexity and above all, a different interface. Part of this is also a search for the ideal API.
ZnClient is the simplest one: some class methods to fire off one shot requests.
ZnFixedClient is useful to connect to a single server and reuse the connection for multiple requests, like with a web services API.
ZnHttpClient is a builder like interface (think of Gofer), it also has some extra features.
ZnHTTPSocketFacade is a replacement for the current
Pharo/Squeak HTTPSocket API. In my development images, this is active, which means that all HTTP functionality (for MC for example) is handled by Zinc HTTP - a case of eating my own dog food.
good!
On the server side there is ZnServer which can be customized with a delegate and authorizer. A static web file server, a Monticello server as well as a Seaside adaptor are available.
Do you port an existing library to smalltalk or do you figure out how it should be done right now? And what do you think about going towards cross-platform? This would need a decision if you are willing to integrate grease/sport in your client. I can imagine that this is not wanted per se because it introduces dependencies. It will be just very hard to do it cross-platform if you do not.
The first goal of Zinc HTTP is to be useful for Pharo, to replace existing HTTP functionality in the image. Hence portability is not high on the list. Like you said, building on top of a portability layer would mean external dependencies that would most probably conflict with the first goal. But I am not against portability (most of the code except for some obvious missing crypto stuff still runs on Squeak as well). We can always try to find a solution.
Regards,
Sven
participants (4)
-
Lukas Renggli -
Norbert Hartl -
Stéphane Ducasse -
Sven Van Caekenberghe