HTTP_Request2

On Tue, Oct 28, 2008 at 7:55 PM, David Jean Louis <izimobil@gmail.com> wrote: > Alexey Borzov a écrit : >> >> Hi, >> >> David Jean Louis wrote: >>>>> >>>>> Ok. I'll try to finalize the parts I've started so far, and I will >>>>> post >>>>> them somewhere so you can check it out and move on setting things up. >>>> >>>> Thanks, HTTP_Request2 is long overdue, hope this time we'll be able to >>>> come up with something. :] >>> >>> Ok, as promised here's the work I've done so far on HTTP_Request2: >>> >>> >>> http://code.google.com/p/izi-sandbox/source/browse/#svn/trunk >>> >>> I took parts/ideas from pear2::HTTP_Request2, Zend fw and >>> pear1::HTTP_Request, the result is 4 individual packages: >>> >>> - HTTP_Common (include a HTTP Message abstract class and Headers >>> container class); >>> - HTTP_Connection: this is where the "adapters" live (I still think that >>> adapters are not a good idea though...); >>> - HTTP_Request2; >>> - HTTP_Response2. >> >> Ouch. I agree with Joshua here, 4 packages are definitely a no-no, >> especially because they are so interdependent. I don't know why this is an issue to be honest. The pear installer keeps track of your dependencies. If people come forward later and what to submit patches, adjust code, they always can. This is opensource and since HTTP_Request2 would start off with a 0.0.1 most likely there is room to improve before a BC-break becomes an issue. Talking for forever won't improve the situation. Again, I don't see an issue and I'd suggest we move forward as is, unless someone wants to provide code. >> Also I think that a better idea is to implement actual request >> functionality first and spice it up with all the relevant SPL interfaces and >> magic __get() / __set() methods afterwards, not vice versa. A good example >> here is your HTTP_Headers class that wraps around an associative array of >> headers and then implements Iterator, ArrayAccess, Countable to make it >> look, well, like a genuine associative array >> > > The idea (taken from pear2::http_request btw) was to have a case insensitive > container for headers, to avoid strtolower everywhere in the code. > >>> the current implementation should support without problems: >>> - chunked/gzip/deflate response, >>> - keep-alive connections, >>> - redirects, >>> - subject/observer pattern, >>> - etc... >> >> I tend to agree with Joshua once again that your implementation would make >> it difficult to leverage available PHP extensions (read: cURL). >> >>> Note that some parts of the code are copy/paste/adapted from others >>> implementations, so I need to add @author/@copyright tags where relevant >>> (this will be done of course, just didn't had time...). >> >> Is verbatim copying from Zend Framework really a good idea? Why not? a) It's BSD-licensed code. b) Why do we need to repeat mistakes of others and re-invent the wheel here if the solution they provide is "good"? Or do you have a objection, e.g. code "sucks" (more detailed reasoning would be awesome ;-))). >> Finally I'd like to suggest we finish hijacking the "Services_oEmbed" >> thread and start a new one. :] Done. :-) > Ok. > > I'm off with HTTP_Request2, I already spent too much precious time on it > yet, good luck guys... > > If someone want to take the code, It will stay on my sandbox. > > I'll just use curl for my projects at work, until something is done or pecl > http is integrated into core. > > Moving to my other things now. That's too bad, David. :-( Till