Matt, On 24 Sep 2010, at 21:02, Matt Kennedy wrote:
> Hi Sven, > > I am interested mostly in the client side right now and will take up your > suggestion of implementing a new client within the Zn components. The client > I started a couple days ago subclassed ProtocolClient and I can lift stuff I > did from that client for a new Zn client. My current client had cookie > handling, chunked encoding, and configurable automatic redirect handling. I > myself am not so much interested in keep alive connection reuse, though it'd > certainly have some use. My main goals for a client library are to support > persistent client sessions, pluggable authentication, and easy header > control, which are things I've found lacking when trying to implement some > web APIs using HTTPSocket. Sounds really interesting, I am looking forward at seeing your code! Sven > I am on the Pharo-project list and squeak-dev currently. I'll make sure I'm > on all the pharo lists so future discussions can happen openly there. > > Matt > > On Sep 24, 2010, at 1:47 PM, Sven Van Caekenberghe wrote: > >> Hi Matt, >> >> On 24 Sep 2010, at 18:01, Matt Kennedy wrote: >> >>> Hi, >>> >>> I wanted to write and thank you for the work you've done here with your >>> library. I just recently started this week on working on a replacement for >>> HTTPSocket because I wanted to implement OAuth for Pharo and HTTPSocket >>> just doesn't cut it. You've got a nice bundle packaged up and are a lot >>> farther along, so I'd much rather support your work. >>> >>> My question for you is how much of the client code from the Old collection >>> of packages are you planning on refactoring into the New packages? I'd like >>> to work on bringing over the session and cookie code and instance side >>> methods of ZnHTTPClient over in order to support making multiple requests >>> from a single client instance and work on an OAuth authenticator, which is >>> what got me started on this road to begin with. >>> >>> Regards, >>> Matt Kennedy >> >> Thanks for your interest. I presume you have read the project's main page >> and getting started guide, especially the Status, Todo & Future sections. >> Those should answer most of your questions. >> >> Now, basic Cookie support should be a standalone class or two (ZnCookie, >> ZnCookieJar). The exesting ones are not that clean, if you know the subject, >> you could do that from scratch. This is not something that I would do first. >> >> Although the current (server side) authenticator is pluggable, it is >> hardwired for basic authentication. Obviously there are other authentication >> schemes. So authenticator should become a more intelligent object that does >> what ZnServer>>#authenticateRequest:do: now does. I could do the refactoring >> (server side) with an abstract superclass and basic authentication as >> concrete subclass. I don't know if server and client side are unifyable. >> >> If you are mostly interested in the client side, I would suggest that you >> try to write your own client, separate from the current one (ZnClient is >> only a very simple class side collection of utilities). One of the first >> things I wanted to do next was a client that reuses connections (as well as >> chunked and gzip encoded transfers). Reusing connections is actually a >> pretty special case when you keep on hitting one server very frequently, >> otherwise the reuse effort is not worth the trouble (re-establising >> connections) - that is what I found in other HTTP clients that I wrote. What >> do you think ? >> >> I am not familiar with OAuth, I just heard about it, something like that >> would be most interesting. But maybe this could be an add-on package, I >> don't known how elaborate it is ? >> >> BTW, are you on Pharo ? I would like to have discussions like this openly on >> the pharo dev list. >> >> Sven > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
