I have a couple of question, not about Zn but the process: 1) Stef, you are talking about just to put Zn in the image or REPLACE all uses of HTTP to use Zn? 2) It may be difficult to replace that since Monticello use it -> be carfeul ! 3) How are you going to depreacate HTTP? 4) Does Zn mantains the same API as HTTP ? what happen with external packages? will the API change?
Cheers Mariano On Sat, Apr 16, 2011 at 3:13 PM, Germán Arduino <gardu...@gmail.com> wrote: > I would like to know exactly what features will provide Zn and which not. > > 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. > > Cheers. > Germán. > > > 2011/4/16 Norbert Hartl <norb...@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 > > > > > > > > -- Mariano http://marianopeck.wordpress.com
