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
