Re: PEAR2_Http_Request / HTTP_Request2

Christian Schmidt wrote:

David Coallier wrote:

Some people configure with sockets, some people don't.

fsockopen() is always there, isn't it? But fsockopen doesn't always work with ssl depending on how things are configured. You can also disable remote connections with a php.ini setting (allow_url_fopen)

Also note we don't really have an adapter that uses fsockopen, we use stream_content_create, though its more or less the same thing. The phpsocket adapter is just an php5ized version of HTTP_Request, with some other refactoring to match the adapter setup, it uses the socket extension which isn't always available but it can't be disabled by an ini setting. Its also the slowest implementation since everything but the actual socket is done in php code not in an extension.

What is wrong with having the choice without the loss of speed ?

Nothing is wrong with choice. I was merely asking why one would want to choose :-) Allowing choice isn't free in terms of complexity, development, QA, etc., though, so I don't believe in adding choice just for the sake of it. That's why I am asking. Very true, though in reality the fsockopen implmentation is the most complicated, the rest is just wrapping c code and is much much easier.

Also preference, some people swear only by curl, some others by streams.

I assume the purpose of making different adapters is to provide a uniform API to the different ways of making HTTP requests in PHP, so why would one care about what's inside? Or are certain adapters expected to have specific features that cannot be implemented in the other? Different adapters will have different features and performance characteristics. This is especially true with the curl and pecl_http which will have the ability to offer some additional features and should be a lot faster on large datasetup.

If different adapters are necessary to allow the package to work on as many platforms/systems as possible, I think it's a worthy goal. On the other hand, I think your example about people compiling a custom version of curl with special features on the surface sounds a bit esoteric :-) Josh wrote to me in private (because I answered his original message in private by mistake) that curl may have a better chance of getting SSL to work than a socket based solution. I don't know how big the problem is in practice, but it may very well be another good reason for allowing choice. Christian

SSL is a big part of it, built in SSL support has gotten a lot better in PHP5 but its generally a lot easier to just rely on curl. -josh