[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.

> 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
>
>
>

> 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

> 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
>
>

>
> 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 <[hidden email]> 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
>

>>> 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