Open Maks3w opened 8 years ago
ping @weierophinney @zendframework/community-review-team
I'd be wary of splitting stuff into more components personally, but only because each extra repository is a hard drain on our resources. @Maks3w - are you saying this library works as a builder/parser, but has too many dependencies to be usable in the real world please?
On a personal note, I'd also like to say that pinging someone for a response only 4 minutes after a ticket is created is a bit off. It's nicer if we wait and give people a reasonable period to reply (particularly those in a different timezone) before specifically pinging them for a response.
I'm with @GeeH here, I do not see the value in separating out the headers from the zend-http component.
I use zend-http only for the ability of parse header information especially in cases where the header may have many parameters or edge cases like Content-Type headers.
As HTTP Client I think Guzzle is the most popular library or any other PSR-7 compatible library so the rest of Zend\Http component is never used.
"As HTTP Client I think Guzzle is the most popular library or any other PSR-7 compatible library so the rest of Zend\Http component is never used."
This kind of statement is not useful. I use Zend\Http\Client all the time in my ZF2 projects, it works, and it's bundled in with the framework, so to say "is never used" is plain wrong.
With that said, I would be happy to open discussion about removing Http\Client from the Zend\Http package because there is a great community alternative available. I'm hoping to open discussion on what can be done here, and was hoping to get an answer to my initial question before making suggestions.
I'll repeat my earlier question:
@Maks3w - are you saying this library works as a builder/parser, but has too many dependencies to be usable in the real world please?
@GeeH Can you explain "has too many dependencies"?
It installs 6 zendframework packages which are not needed for parse/build the headers. Just unused stuff, things we are trying to avoid in the new generation of micro frameworks (Slim, Expressive, ...)
Ok, so the number of dependencies (6), could be thought of as being too many if you only want to use the parsing/building parts.
I need to take a look at these dependencies etc before I can agree with a repository split. Can we reduce the number of dependencies? Can we make some optional? I'll take a look at get back to everyone.
:)
This repository has been closed and moved to laminas/laminas-http; a new issue has been opened at https://github.com/laminas/laminas-http/issues/21.
Currently there is a lack of HTTP header builder / parser in the PHP community ecosystem.
I suggest move
Zend\Http\Header
namespace to an standalone component for better reusability.Actually
zendframework/zend-http
installs 6 packages, 4 direct dependencies + 2 indirect dependencies.The proposed roadmap is move the subcomponent files to the new repository under the Composer's name of
zendframework/zend-http-headers
and make it a requirement ofzendframework/zend-http
The following files are excluded from these movement and should be keep in this repo.
HeaderLoader
AZend\Loader
plugin loader of header files.Headers
A headers collection which is not reusable for PSR-7 interfacesBC Breaks: Generally speaking there is no BC Breaks but Header exceptions won't inherit from
Zend\Header\Exception anymore