Re: [Pharo-project] [Progress Report] Zinc HTTP Components
Cool! Stef On Oct 1, 2010, at 10:04 AM, Sven Van Caekenberghe wrote:
Here is a quick progress report regarding the Zinc HTTP Components project. Please check the SqueakSource history for a all the details. The external documentation has not yet been updated ;-)
I am very pleased that Matt Kennedy joined the project as a developer and is contributing lots of really important and interesting code - way to go Matt!
Some highights are:
- we now have cookie handling, authentication and credential objects - there is a new ZnUserAgent client that can do advanced authentication handles cookies, sessions and that can follow redirects - there is a ZnFixedClient that can reuse a connection to the same host/port - there is support for client side chunked and gzip decoding - there is an experimental server that keeps connections alive (unfinised) - support classes ZnUserAgentSession and ZnUserAgentSession - lots of refactorings, fixes and portability improvements - the number of unit tests has increased to 71
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Wow, very impressive. What I would like to see is some kind of high-level API for convenient access to all features. Something along response := ZnHttp new url: 'http://www.foo.com'; userAgent: 'FakeAgent'; cookieAt: 'something' put: '123'; parameterAt: 'q' put: 'smalltalk'; onFailure: [ :error | self inform: 'failed' ]; onProgress: [ :status | ... ]; get Lukas On 1 October 2010 13:52, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Cool!
Stef
On Oct 1, 2010, at 10:04 AM, Sven Van Caekenberghe wrote:
Here is a quick progress report regarding the Zinc HTTP Components project. Please check the SqueakSource history for a all the details. The external documentation has not yet been updated ;-)
I am very pleased that Matt Kennedy joined the project as a developer and is contributing lots of really important and interesting code - way to go Matt!
Some highights are:
- we now have cookie handling, authentication and credential objects - there is a new ZnUserAgent client that can do advanced authentication  handles cookies, sessions and that can follow redirects - there is a ZnFixedClient that can reuse a connection to the same host/port - there is support for client side chunked and gzip decoding - there is an experimental server that keeps connections alive (unfinised) - support classes ZnUserAgentSession and ZnUserAgentSession - lots of refactorings, fixes and portability improvements - the number of unit tests has increased to 71
Sven
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
Lukas, On 01 Oct 2010, at 14:10, Lukas Renggli wrote:
What I would like to see is some kind of high-level API for convenient access to all features. Something along
response := ZnHttp new url: 'http://www.foo.com'; userAgent: 'FakeAgent'; cookieAt: 'something' put: '123'; parameterAt: 'q' put: 'smalltalk'; onFailure: [ :error | self inform: 'failed' ]; onProgress: [ :status | ... ]; get
A bit like Gofer I guess... It certainly looks cool, the code above. I'll have to think a little bit about that approach. How should such an object handle wrong use of the API ? What if I don't specify an url, do the get before setting the cookie, ... It feels as if there will be little feedback in terms of errors, no ? Sven
response := ZnHttp new   url: 'http://www.foo.com';   userAgent: 'FakeAgent';   cookieAt: 'something' put: '123';   parameterAt: 'q' put: 'smalltalk';   onFailure: [ :error | self inform: 'failed' ];   onProgress: [ :status | ... ];   get
A bit like Gofer I guess...
Yeah, the pattern is always the same :-) Seaside rendering, Gofer loading, Magritte description, ...
It certainly looks cool, the code above.
I'll have to think a little bit about that approach.
The idea is that reasonably complex scenarios can be written as a single expression.
How should such an object handle wrong use of the API ? What if I don't specify an url, do the get before setting the cookie, ... It feels as if there will be little feedback in terms of errors, no ?
If you forget to specify an URL you'll likely get an exception at some (later) point. If you forget or do something after #get, #put, #delete, #head, ... it has no effect. Also you don't get the result, which is returned from these methods. In my opinion the missing feedback is not a problem in practice, people just have to remember to do the action last. Lukas -- Lukas Renggli www.lukas-renggli.ch
Hi everyone, On Oct 1, 2010, at 8:10 AM, Lukas Renggli wrote:
Wow, very impressive.
What I would like to see is some kind of high-level API for convenient access to all features. Something along
response := ZnHttp new url: 'http://www.foo.com'; userAgent: 'FakeAgent'; cookieAt: 'something' put: '123'; parameterAt: 'q' put: 'smalltalk'; onFailure: [ :error | self inform: 'failed' ]; onProgress: [ :status | ... ]; get
Lukas
This is actually where I'd like to head with the client API. I had started my own HTTP client about 2 days before Sven announced Zinc, so it made more sense contribute to his project. My initial work was a subclass off of ProtocolClient and was kind of monolithic, so my first steps have been to make things mesh nicely with Zinc. My initial prototype before I started working on Zinc had a very similar API to your example, so my thoughts are definitely aimed for that direction. Matt
participants (4)
-
Lukas Renggli -
Matt Kennedy -
Stéphane Ducasse -
Sven Van Caekenberghe