On Apr 16, 2011, at 3:52 PM, Mariano Martinez Peck wrote: > 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? what would be the point? Key a crappy implementation? For what purpose
> 2) It may be difficult to replace that since Monticello use it -> be carfeul > ! No sven already use it since months for that > 3) How are you going to depreacate HTTP? ? Simply. Fixing all the clients. > 4) Does Zn mantains the same API as HTTP ? Why should it be? > what happen with external packages? They will have time to migrate. > will the API change? probably since the current one is plain bad. > > 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 >
