Re: Base64 Decoding

[Michael Ryan <michaelrtr@xxxxxxxxx>]

   Thanks Scott...what version of HTTPAPI has this function?
   - Michael

   On Mon, Aug 2, 2010 at 2:18 PM, Scott Klement <[1]sk@xxxxxxxxxxxxxxxx>
   wrote:

     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][2]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][3]http://www.scottklement.com/mailman/listinfo/ftpapi
     >
     -------------------------------------------------------------------
     ---

   >     -
   >
   > References
   >
   >     1. mailto:[4]sk@xxxxxxxxxxxxxxxx

     >     2. [5]http://www.scottklement.com/mailman/listinfo/ftpapi

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

References

   1. mailto:sk@xxxxxxxxxxxxxxxx
   2. mailto:sk@xxxxxxxxxxxxxxxx
   3. http://www.scottklement.com/mailman/listinfo/ftpapi
   4. mailto:sk@xxxxxxxxxxxxxxxx
   5. http://www.scottklement.com/mailman/listinfo/ftpapi
   6. http://www.scottklement.com/mailman/listinfo/ftpapi
   7. 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
-----------------------------------------------------------------------