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)

Saturday January 11, 2003
06:23 AM

RPC::XML and Hasty Decisions

[ #9899 ]

When I initially wrote the serialization/deserialization code for the RPC::XML package, it was after all meant to be a reference implementation from which I wrote extensions to the XML-RPC protocol. When that stirred up a storm of shit with Dave Winer, I decide to focus on code rather than ego, and instead made it a conformant XML-RPC implementation.

But there was a little trap waiting for me, patiently...

I designed it serialize and deserialize in memory. Even as I wrote support for the Base-64 datatype and wrote tests to validate it, I didn't think about how big something sent as a Base-64 chunk would likely be.

A project I'm working on at the day job will be using the package to move Base-64-encoded WAV files. That's pretty damned big. And suddenly, keeping it all in memory is a really bad idea. So I'm spending my weekend coming up with a streaming layer for serialization and deserialization in the package. 'Cause I'm going to need it on Monday when I get back into the office.

For every complex problem there is a solution which is simple, neat and wrong.  H.L. Mencken

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.
  • When I was thinking about the successor to the XML-RPC, this was one subject I wanted to cover. I think you can either chunk the data over several messages (which the client has to know to assemble) or you simply give a URL pointer to the data, which can be downloaded over vanilla HTTP. Both of these solutions are, I admit, hella lame.
    • The specific case that's driving this development suffers from more design woes than just this. But at present, I have to be prepared to fetch WAV data that was sent as an e-mail attachment (!) over an XML-RPC interface.

      And it has occurred to me that even as I do all this work this weekend, I have no idea if their server (for which the XML-RPC component is very new and highly experimental) can even deal with that much data in a single message. They, too, may suffer from having code that expects to read all

      --

      --rjray

    • This is where xlink would be very appropriate, and where Dave Winer needs to get off his high horse about namespaces - they would be very useful here.