Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

rjray (1649)

rjray
  (email not shown publicly)
http://www.rjray.org/
AOL IM: rjrayperl (Add Buddy, Send Message)
Yahoo! ID: rjray_perl (Add User, Send Message)
Jabber: rjray@jabber.org

Journal of rjray (1649)

Wednesday January 15, 2003
06:48 PM

Creative Content for HTTP::Request

[ #9998 ]

The HTTP::Message class of LWP (from which the HTTP::Request is a sub-class) allows a subroutine reference (or closure) as the argument to the content() method. When the content is given as this sort of reference, it is repeatedly called for data until it returns either undef or an empty string.

This will be key to my implementing streaming of messages in RPC::XML. But it isn't really documented at this point, so I thought I'd share.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Creative Content for HTTP::Request 2 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I understand that you're trying to work around the large XML message problem. I take it you're not worried about validating this bloody message, rather you want to get at the data? Perhaps you'd consider just sending a pointer to the data which can then be served over standard HTTP. I think this solution keeps the XML message managable and lets RPC::XML do what it does best: small messages. I realize this is a somewhat unsettling suggestion, but I smells like the right solution to me. If you go down the roa

    • The problem is that the 3rd-party system we're working with uses an XML-RPC interface, but the data being sent is going to be huge. The goal is to avoid constructing the XML-RPC messages as in-memory strings, since they will be including base64 values that are encoded audio attachments.

      The fact that I prefer not to back down on my existing compression support makes it harder, but I'm not going to back out a generally-useful feature like that in the name of a specific-requirement feature.

      Matts [perl.org] made a good

      --

      --rjray

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.