Re: Http_download isnt on github yet (?)

> I'm torn – HTTP_Response_Download? But that may overcomplicate things. Oh, hell no :-D > IMHO, the more I think about it, the better HTTP_Download seems. I am sure > somewhere a while back, people had the same train of thought. Perhaps they thought HTTP_Request would use HTTP_Response for its responses, and so decided to use HTTP_Download to avoid conflicts. But seeing that in the end, HTTP_Request(2) uses something else, this ended up as an unnecessary caution. > Also, as a side-effect – HTTP_Download2 with an identical API (if possible), > makes upgrading for people a lot, lot easier. An HTTP_Response with an API identical to HTTP_Download would be just as easy to upgrade - this one refactoring of the files that call HTTP_Download will be requred anyway. The only difference is what you set as the "replace" in your "search&replace". And there will be a "deprecated" message in the PEAR site/installer either way... or am I missing something else? 2012/1/9 till <till@php.net>: > > > On Mon, Jan 9, 2012 at 6:33 PM, Vasil Rangelov <boen.robot@gmail.com> wrote: >> >> Actually, I think I just had an idea for a name that would convey the >> purpose a lot more unambiguously: HTTP_Response. Since it's the server >> that gives responses, this clearly conveys the package is a server >> helper. HTTP_Request(2) uses HTTP_Request(2)_Response for its >> responses, so there won't be a conflict. >> >> Thoughts? > > > I'm torn – HTTP_Response_Download? But that may overcomplicate things. > > IMHO, the more I think about it, the better HTTP_Download seems. I am sure > somewhere a while back, people had the same train of thought. > > Also, as a side-effect – HTTP_Download2 with an identical API (if possible), > makes upgrading for people a lot, lot easier. > > Till >