[Pharo-project] About Zinc to replace HTTPClient

Jan van de Sandt jvdsandt at gmail.com
Sat Apr 16 19:44:18 CEST 2011


Yes, CloudforkSSO has support for OAuth1, AOuth2 and OpenID. Cloudfork uses
Zinc as HTTP client library. Works very well.

Indeed, SSL is not supported directly. But using stunnel [1] is a good
workaround for this.


[1] http://blog.doit.st/2011/02/23/cloudforksso-on-pharo-with-stunnel/

On Sat, Apr 16, 2011 at 5:37 PM, Norbert Hartl <norbert at hartl.name> wrote:

> Am 16.04.2011 um 15:13 schrieb Germán Arduino:
> > I would like to know exactly what features will provide Zn and which not.
> >
> What do you mean with features?
> > As I remember form the past was not planned to support for example
> > https, which prevent to use OAuth and OpenID, very needed to develop
> > any interaction against any modern web site.
> >
> Zinc is http handling components. Https is just a http request over a
> transparently initiated SSL connection. So if you have SSL you have https.
> It is not the duty of an http component to support SSL. A url handler needs
> to integrate existing SSL.
> As far as I remember the cloudfork guys have OAuth running. So they must
> have SSL. So it shouldn't be to hard to do the same with zinc. Just exchange
> the http handling routines.
> Norbert
> > 2011/4/16 Norbert Hartl <norbert at hartl.name>:
> >>
> >> Am 15.04.2011 um 22:12 schrieb Stéphane Ducasse:
> >>
> >>> Hi guys
> >>>
> >>> we discuss with sven about strategies to get a better infrastructure
> and the HTTP level.
> >>> Sven would like to have feedback on Zinc before pushing it in Pharo :)
> >>> So can you let us know. What we could do it to have it in a preview in
> 1.3
> >>> then in 1.4 remove HTTPClient (or friend).
> >>
> >> This is really good. To me (meaning  IMHO) it is one of the most missing
> functionalities in pharo. Zinc is really great and so much better than
> _anything_ in pharo that pretends to do HTTP. I would like to see it that we
> don't talk about HTTP but about proper MIME based communication. I think the
> very core that is in there is the structured and flexible mime media
> handling and communication. And this is not only true for HTTP but also for
> email.
> >> I would like to see that Zinc creeping into the image bringing the mime
> stuff along. Than the mime stuff should break loose of the Zinc components
> and should replace the mime handling that is in the image. Than we have it
> for http and for mail sending and for every other transport protocol you can
> imagine.
> >> And now that Paul ported zinc to gemstone you can develop good http
> handlers that are easily ported to gemstone. What a wonderful world!
> >> And seaside? Well, if the current http adaptors are much faster than
> zinc than there should be shortcut path through zinc that allows fast
> handling of the minimal stuff seaside needs. The same problem goes for the
> WARequest stuff. Using zinc you can get access to the mime parts. Now
> WARequest is a strange request object that contains a dictionary for request
> parameters and a raw message body. If only compatibility is important than a
> zinc to old WARequest handling is needed. But I would like to see the mime
> based handling to be the "normal" way of doing and not vice versa. But I can
> see that it must be a special treatment as seaside is ported to so many
> platforms that don't have zinc. Probably one reasone more to extract the
> mime stuff. It might be a promininent candidate other platforms adopt.
> >>
> >> my two cents,
> >>
> >> Norbert
> >>
> >>
> >>
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110416/292273b5/attachment.htm>

More information about the Pharo-project mailing list