Hi Evan,

On many 'sane' PHP hosts the 'allow_url_fopen' directive is turned off
and Curl may not always be available. In this situation you have to
resort to fsockopen or stream_content_create. It would be nice if
Laconica's HTTP client code is flexible enough to encompass these
options.

Regards,
Bo

On Sun, 2009-05-17 at 12:09 -0400, Evan Prodromou wrote:
> Hello, everyone. As people who've poked around in the Laconica
> codebase know, we have a lot of different HTTP client access methods:
> curl, file_get_contents(), the Yadis tool's HTTPFetcher, and maybe
> even others.
> 
> In Laconica 0.9.x, I would like to have a single HTTP client class
> that all HTTP client code uses (except our external libraries, of
> course).
> 
> The benefits to the admin are that he/she doesn't have to worry about
> dependencies. To developers, our code becomes more readable. Also,
> improvements to the client class will improve all HTTP-using code.
> 
> I see a few options:
>       * Use the PEAR HTTP_Client or HTTP_Request (or effin'
>         HTTP_Request2... stupid PEAR) tools. Of these, I like
>         HTTP_Request2, since it seems to use pluggable engines.
>         http://pear.php.net/packages.php?catpid=11&php=all
>       * Always use curl, and always require curl. Maybe not such a bad
>         idea, although I think the curl programming interface is
>         horrible.
>       * Use PECL's HTTP client class, and require it.
>       * Write our own wrapper class, which uses whichever is the best
>         available HTTP client method.
> Some things I'd like to add to our HTTP client functionality, no
> matter what:
>       * Caching of HTTP results in memcached; using If-Modified-Since,
>         If-Not-Match to only get stuff from a server if the cache is
>         out of date.
>       * Follow HTTP redirects automatically.
>       * Don't get into HTTP redirect loops.
>       * Sane timeouts and size limits for requests.
> My current feeling is that we should have our own wrapper class. Yet
> more extra code, but it seems like the most efficient, best chance for
> clean code, and best chance to use available resources effectively.
> 
> Any feelings on the subject?
> 
> -Evan
> 
>         
> 
> _______________________________________________
> Laconica-dev mailing list
> [email protected]
> http://mail.laconi.ca/mailman/listinfo/laconica-dev

_______________________________________________
Laconica-dev mailing list
[email protected]
http://mail.laconi.ca/mailman/listinfo/laconica-dev

Reply via email to