|
»
« Return to Thread: Http_download isnt on github yet (?)
Re: Http_download isnt on github yet (?)
by Vasil Rangelov
::
Rate this Message:
> 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@...>:
>
>
> On Mon, Jan 9, 2012 at 6:33 PM, Vasil Rangelov <boen.robot@...> 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
>
--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
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@...>:
>
>
> On Mon, Jan 9, 2012 at 6:33 PM, Vasil Rangelov <boen.robot@...> 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
>
--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
« Return to Thread: Http_download isnt on github yet (?)
| Free embeddable forum powered by Nabble | Forum Help |
