use Perl

• Interesting (Score:2)

  by jjohn (22)

  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
  • Re:Interesting (Score:2)

    by rjray (1649) on 2003.01.16 17:05 (#16098) Homepage Journal

    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 point that XLink would work really well in a case like this, but XML-RPC doesn't support that. And since this is a generalized remote-email interface, I can't reasonably ask them to implement oddness like recognizing a URL and downloading it to use as the attachment-in-question.

    It's all terribly messy, and gets more and more frustrating with each passing day. Other problems and limitations have recently arisen, too, but at least most of those are someone else's headache.

    --
    

    --rjray

    Reply to This

    Parent