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