Re: Base64 Decoding

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Hi Michael,

HTTPAPI has a feature where it can return XML element data using a 
pointer and length.  This was intended to circumvent the 64k limit that 
RPG had for a single string.

It works like this:

      callp http_XmlReturnPtr(*ON);

This forces HTTPAPI to send you a different parameter for the XML data 
in your "end handler" (peEndProc).  Instead of your end handler's 
interface looking like this:

D EndProc         PI
D   userdata                      *   value
D   depth                       10I 0 value
D   name                      1024A   varying const
D   path                     24576A   varying const
D   value                    32767A   varying const
D   attrs                         *   dim(32767)
D                                     const options(*varsize)

It should now look like this:

D XmlValue_t      ds
D   data                          *
D   len                         10i 0

D EndProc         PI
D   userdata                      *   value
D   depth                       10I 0 value
D   name                      1024A   varying const
D   path                     24576A   varying const
D   value                             likeds(XmlValue_t)
D   attrs                         *   dim(32767)
D                                     const options(*varsize)

The subfields of 'value' in the above example are 'data', which is a 
pointer to the value of the XML data, and 'len' which is the length of 
the data at that spot in memory.

You can easily pass them to the IFS write() API to write them to disk:

     fd = open( ... );
     callp write(fd: value.data: value.len);
     callp close(fd);

This would write the entire contents of the XML element to disk in one 
swell foop.

Good luck

On 8/2/2010 12:19 PM, Michael Ryan wrote:
>
>     Perry White? Editor in Chief of the Daily Planet? Or is it Mr.
>     Mxyzptlk? Backwards?
>     So I'm using the HTTPAPI wrapper (Ice...Ice baby) and it's returning
>     an element for each chunk. I'm currently writing that to a file in
>     preparation of the Base64 decoding. But I'm thinking I can probably
>     put all this together...get a piece of data, compress out white space,
>     decode it, write it to a file.
>     Then I need to print the file as a PDF.
>     1985 was a good year.
>
>     On Mon, Aug 2, 2010 at 1:02 PM, Scott Klement<[1]sk@xxxxxxxxxxxxxxxx>
>     wrote:
>
>     On 8/1/2010 9:45 AM, Michael Ryan wrote:
>     >  Thanks for the info. I'm able to decode the MIME-64 attachment, but
>     >  I'm running into another (bigger?) problem. I'm using your port of
>     >  eXPat to parse through the XML document. However, the element value
>     >  that will contain the PDF document can easily be over 100K in size!
>
>       (GASP!) (Lights hair on fire and runs around in a circle
>       screaming.)
>
>     >  I received a test document that was 150K, with the PDF document
>     >  comprising 120K of the total.
>
>       150K!  120K!  Great caesars ghost! The only power source capable of
>       generating 1.21 gigawatts of electricity is a BOLT OF LIGHTNING!
>       But
>       nobody knows where one will strike...
>
>     >  Will eXpat handle elements this size?
>
>       Without breaking a sweat.
>
>     >  Will the parser provide multiple iterations of the same element data
>     >  which I could then write to a file for later retrieval using a
>     >  Base64 decoding scheme?
>
>       Sure... if done correctly.  Are we really talking about Expat, or
>       are we
>       talking about HTTPAPI's wrapper for it?
>
>     >  Any ideas on how I can process this big element?
>
>       We'll see if we can harness a bolt of lightning and get you back to
>       the
>       future, in 1985, where it's easy to handle such large volumes of
>       data.
>
>     ----------------------------------------------------------------------
>     -
>     This is the FTPAPI mailing list.  To unsubscribe, please go to:
>     [2]http://www.scottklement.com/mailman/listinfo/ftpapi
>     ----------------------------------------------------------------------
>     -
>
> References
>
>     1. mailto:sk@xxxxxxxxxxxxxxxx
>     2. http://www.scottklement.com/mailman/listinfo/ftpapi
>
>
>
>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------