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