an HTTP client upon a buffer-based IO, please?

1.  The questions

	Do I understand it correctly that the most of the libwww HTTP
	implementation is tied together by the means of the
	LWP::Protocol::http module, while LWP::UserAgent just invokes
	scheme-specific protocol handlers?

	I need for the libwww HTTP client to use two scalar values as
	the read and write buffers for communication instead of a, say,
	IO::Socket::INET6 instance.  Do I understand it correctly that
	in order to do that I will have to:

	• define my custom classes (say, LWP::Protocol::http::MyBuffers,
	  …::SocketMethods and …::Socket) based on LWP::Protocol::http,
	  …::SocketMethods and …::Socket, respectively, that overload:

	  – …::MyBuffers: none, but calls to socket_class () are now
	    ought to return …::MyBuffers::Socket, right?

	  – …::MyBuffers::SocketMethods: can_read () is to die unless
	    given an argument of zero; sysread () is to no longer call
	    the “real” sysread ();

	  – …::MyBuffers::Socket: should no longer be based on Net::HTTP
	    (as the latter is derived from IO::Socket::INET), but
	    instead on, say, Net::HTTP::MyBuffers, itself derived from a
	    custom IO::Handle-like class (say, IO::Handle::MyBuffers)
	    and Net::HTTP::Methods;

	• define a custom IO::Handle-like class (IO::MyBuffers)
	  implementing the following methods:

	  – sysread (), syswrite () and print (), as these are used by
	    LWP::Protocol::http for I/O;

	  – blocking (), peerhost (), peerport (), that are stubs;

	  – _rbuf ()? I've failed to find where this method is defined?

	Also, do I understand it correctly that
	LWP::Protocol::http::request () won't fit since it uses
	select ()?

2.  Background

	Bitflu (a BitTorrent implementation) currently implements an
	ad-hoc HTTP client, mainly in order to enable .torrent and RSS
	downloads.

	It's my intent to replace this client with an libwww-based one.

	By design, a Bitflu plugin should not perform I/O by itself, but
	should instead rely on the API provided by the Bitflu engine.
	The latter could roughly be summarized as follows:

	• …->NewTcpConnection (%parameters) — establish a connection;

	• …->WriteData ($token, $data) — queue data to be written.

	There's no function to read data, as the engine invokes a
	callback function instead.

	I guess that I could implement a buffer-based IO::Handle-like
	class and use it as a (part of the) glue between Bitflu's engine
	and the libwww HTTP implementation.

3.  Acknowledgements

	Okay, in the end it seems that the IO-like class mentioned above
	is way too similar to the String Ports feature, commonly found
	in Scheme implementations.

http://srfi.schemers.org/srfi-6/srfi-6.html

-- 
FSF associate member #7257

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkvf+AEACgkQ+MvqjYjLOAxGAgCfZLNj2Ovmtxnwkxcf280t8DBS
+8AAnRC5/lu6npMRgzOs95xuaRJ2ObUk
=7vN7
-----END PGP SIGNATURE-----