[wp-hackers] HTTP API Refactoring

[Jacob Santos]

I went ahead and started to refactor the HTTP API to make it either suck 
more or suck less. I'm not happy with the design of the architecture. It 
is very restrictive in that in order to add something, you have to 
modify the core and that is not how I would have liked it.

The second problem is that the arguments aren't completely supported in 
all of the transports. I had wanted for the developer to do this:

$request = new WP_Http_Fsockopen('http://www.google.com', 
array('whatever' => 'what'));

But most of the arguments aren't supported, so I thought that instead of 
abstracting the arguments, I would refactor the entire request process 
into something like this:

$request = new WP_Http_Request('http://www.google.com');
$request->override_defaults(array('user_agent' => 'Custom'));
$request->set_transport('WP_Http_Fsockopen');
$request->send();

It is a bit more work , but it allows for someone to use any transport 
separately from WP_Http, which restricts to just the ones that actually 
work and in a specific order.

I already started work on it and I'm moving a lot of the code from 
WP_Http into their own classes, so that the Header code will be managed 
by its own class, since a lot of the code in the HTTP API classes deals 
with headers.

Any ideas? I'm still not exactly sure how to make it to where 
modifications could be plugins, but well, the filters should be used. At 
least with this proposal, the request class can be extended or replaced 
in the WP_Http class. I'm about a third or half way finished.

Jacob Santos