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
pgp3gj90Y1iqk.pgp
Description: PGP signature
