Re: reading pdf/html from ifs send via cgidev2

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

> I'm not familiar with the Location: header technique, but I'm not sure
> what you mean by it being just a link to the document.
A Location: field is an HTTP header field that causes the browser to 
"redirect" to a different spot.  For example you could change your code to 
look like this:
C                   eval      OutStr = 'Location: ' 
C                             + '/webdirectory/pdfs/mypdffilename.pdf'
C                             + $CrLf + $CrLf
C                   exsr      $APIStdOut

Though, there's a difference... yours opens in a separate window.  Thsi 
just tells the browser to go to a different location, but it stays in the 
same window.

> It's my assumption that he's creating these pdfs on the fly - based on
> selection criteria prompted from a browser.  when the user hits the
> submit button, the cgi runs, generates the report and converts it to
> pdf.  now the user needs to see it, so my solution automatically opens
> a browser window with the pdf file's path and name already embedded.
What happens if two users run the CGI program at once?   Won't the PDF 
file in the IFS be overwritten by the 2nd user, causing the first one to 
get a strange response?
Or is a separate IFS file generated for each request?  If so, wouldn't you 
then need some way to clean up old files?  Couldn't a malicious user use 
this against you by filling up your hard drive with lots and lots of PDFs, 
potentially causing your system to crash?
This is why I go back to the same thing each time.  If you're going to 
generate the document on-the-fly, why write it to the IFS?  Just write it 
directly to the browser!

> So, the user presses submit, and the next thing he sees is the report
> pdf in a new window.  how is that just a link to the pdf?
Because that's all your sending back to the browser.  A link to the PDF. 
Granted, the browser is acting upon that link automatically, not waiting 
for user to click on anything, but it's still a link, as opposed to 
returning the document itself.

> If all you are looking for is just a web inquiry, then writing the
> report results in HTML is certainly an option.  But if you want to
> print the output, html reports are not printer friendly, pdfs are.
I don't understand why you're bringing this up?  Did someone dispute the 
validity of PDF as an option?  I certainly didn't.

> So, I'm not aware of any way of generating a pdf from an RPG file
> without writing a spool file first.  Is that what you're saying?  that
> he can write directly from RPG to pdf format?
Why?  Does someone come in your office, put a gun to your head, and say 
"You MUST write the data to the spool, or I'll pull the trigger!".  Why do 
you feel that it must be written to the spool?  Or to the IFS, for that 
matter?  Why not write it directly to the browser?
Perhaps a particular software package expects input to come from a spooled 
file, and written out to the IFS.  If so, that would be one reason why you 
MUST go to the IFS first....   However, if you're the one writing the 
software that generates the PDF (for some reason, this was what I was 
expecting) then you can write it anywhere you like, including writing it 
directly to the browser....