[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[xmlblaster] Re: Using base64 encoding with Frontier::Client

It turns out that by adding an empty second argument string to the
MIME::Base64::encode() method, it is possible to generate an encoded
string that does not contain line breaks. Using this mechanism, when
combined with using the Frontier::Client::base64() method to create
a <base64> data container, solves the problems that I was seeing.

I guess it helps to RTFM ;-/  And thank you for creating such a nice
message system that provides support for us Perl hackers!

Earlier, on 04-Apr-2006 at 2:51 AM, I wrote:

We are starting to use xmlBlaster, and are using version 1.1.1.
I need to publish a serialized Perl object in a <base64> value. I
am using the Perl Frontier::Client module to publish the message.
However, the <base64> value returned to my subscriber Perl script
does not work: it appears that xmlBlaster has modified the content.

When I capture data on the wire, the original serialized and base64
encoded object published to xmlBlaster appears in the first example,
below. The encoded data has one line feed between "...VJO" and "CIE..."
(in case email adds extra line breaks the first example should be four
lines, and the second example is one single line).

Capturing data sent to the subscriber shows that the string has been
modified to become "...VJO/CIE..." which fails to decode successfully
when the message is received. (As a test, changing the "/" back into
a linefeed in the subscriber does allow the message to be successfully
decoded and converted back into a Perl object.)

As an alternative, if I base64 encode the serialized Perl object and
publish it in a <string> value, the subscriber DOES get the original
value returned. However, in this case, Frontier::Client encodes the
the string a second time. It then requires TWO decoding calls in the
subscriber before the data can be successfully converted back into a
Perl object.

Is there a trick to publishing <base64> values? Or a workaround to
prevent overhead of encoding and decoding <string> values twice?

Thank you,

# Excerpt: Message published to xmlBlaster (data on the socket)



# Excerpt: Message returned to subscriber (data on the socket)