On Fri, Oct 31, 2014 at 4:29 PM, Will Fitch <willfi...@php.net> wrote:
> > On Oct 31, 2014, at 4:21 PM, Sherif Ramadan <theanomaly...@gmail.com> > wrote: > > > > On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch <willfi...@php.net> wrote: > >> >> >> >> While not too specific to Rowan, reiterating the pecl/http approach is >> indirectly what your asking for? I have mentioned this numerous times, but >> you haven’t responded with a reason not to take this approach - which is an >> RFC that was presented for discussion prior to yours. > > > I'm trying to understand how pecl/http solves the aforementioned problem > any better? Again, I have no problem with competing ideas and it's not as > though one is prohibited from presenting an idea for the mere fact that > there exists a competing one. I'm just not seeing how pecl/http solves the > problem I intend to solve better. The reason I haven't responded to you yet > is because I'm stilling weighing the two to try and make sense of whether > or not these are in fact competing ideas or complimenting ones. > > Please, feel free to weigh in with anything that contradicts or concludes > what I'm saying. I certainly don't expect to have all of the answers. > > > What doesn’t pecl/http solve under your situation? The fact that’s it’s > not directly integrated as part of ZE and handling process? > Well, you're the one suggesting an alternative. The onus is on you to prove that it solves the same problem, not me. However, I'll bite for the purposes of moving the discussion along... As far as I understand, pecl/http attempts to solve a much larger scope of problems than this RFC. Namely, dealing with HTTP messages in general, whether they are a part of PHP's request/response model or not. i.e. there is no direct integration of the PHP request into pecl/http and as such it doesn't directly solve a problem such as properly parsing the HTTP request body during a PUT request and properly populating the $_FILES/$_POST superglobals. It also doesn't solve similar problems where a transport message body is sent entirely in JSON to PHP and PHP is responsible for handling. Of course, yes, you can do accomplish this today with some hacks like using the php://input stream, but it's only up until recently that this stream has become reusable. It's also potentially creating some duplication, but albeit this isn't the only problem. This RFC also attempts to make it possible for users to directly apply filters to input from the HTTP request so that they can simply retrieve the fitlered data from the HttpRequest object directly without having to do things like $foo = isset($_POST['foo']) ? filter_var($_POST['foo'], FILTER_VAR_INT) : 0; // for example I have nothing against pecl/http. I think it's a very useful library and Mike seems to have put a great deal of work into it. I would gladly vote it into PHP core. I'm just not clear on how it solves the same problems this RFC attempts to solve. They can actually compliment each other in some areas; I can see that. > > I certainly have no problem with competing ideas either. However, the only > proposed patch in this RFC is a gist with PHP pseudocode. > > > > It's not pseudocode since it's actually perfectly valid PHP code that will compile and run in the PHP interpreter. However, it is intended to demonstrate the behavior. The pecl/http RFC is also further along as it's in discussion phase with an actual implementation. This RFC is merely a draft, with no actual implementation proposed yet (but that's not at all uncommon as many RFCs proposed in PHP did not provide an actual implementation until after they were voted in: generators, list in foreach, and finally are among a small number that come to mind). So let's not get hung up on implementation being the barrier to entry for an RFC as that's never ever been the case in the past. It is, however, entirely understandable that the RFC should explain the actual behavior and consequences as well as possible if it does not provide an actual implementation. This is just a very early stage discussion to gather ideas so that I can improve and finalize the RFC. I have not actually placed the RFC into discussion or voting phase just yet. So let's not put the cart before the horse.
