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)

Monday January 13, 2003
03:55 AM

Hasty Decisions Part II: I Did What?

[ #9922 ]

Over the course of the weekend, I've added support to the Base-64 handling within RPC::XML for file-handles in place of static data, and also for serialization of messages directly to an open filehandle (such as a socket) so that messages created for my project at Tellme, which has to sling around encoded WAV files, doesn't choke the hell out of the servers. (Re: my previous journal entry.) I'm actually quite happy with it-- not only is it there and relatively clean in appearance, I've added two more test suites to cover the file-handling and serialization functionality. All told, I've added 40 new tests to the package's test suite so far. More tests are always good.

With all this cozily checked-in to my CVS repository (because I'm exactly that anal when it comes to personal code development), I then turned my attention to the RPC::XML::Client, RPC::XML::Server and Apache::RPC::Server classes. These are the consumers of the data classes, after all. It is they that currently stringify the entire messages to determine Content-Length and to set content in the LWP transport classes. Can't be that hard to convert-- sure, it'll be tricky with LWP::UserAgent, but it can be done. And both server classes give me access to socket descriptors that I can pass directly to the newly-crafted serialize() methods.

But wait... what's this? My compession support...?

It seems that I also use the fully-stringified message to determine if the message should be compressed. If so, I compress it in-memory, and re-evaluate the content-length after it's been compressed. I don't want to back-out my compression support, especially not in this case where I know the code I'm adding is specifically geared towards enabling larger messages.

Right now, I'm leaning towards a tied-filehandle package and making two passes over the message when compression is enabled. The first pass would be to calculate the length of the compressed stream, the second to actually stream it. I'm poring over the man page for Compress::Zlib to begin with, for now. Anyone who's done anything like this is invited to offer advice.

We will never have true civilization until we have learned to recognize the rights of others.  Will Rogers

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.