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