Re: Finding the right PDF module

Of course since this is a web app, I don't want to create the files, just the output stream

I do not know what is so "of course" about that.

Webservers are very good at serving files. Writing the PDF to the server's filesystem is likely to be faster than issuing a stream and waiting for any slow link in the chain to the client. Your script will terminate faster and be ready for another request, while the web-server can take all the time needed to get the file to the client.

CountZero

A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

Comment on Re: Finding the right PDF module

Replies are listed 'Best First'.
Re^2: Finding the right PDF module by pklausner (Scribe) on Aug 16, 2011 at 12:36 UTC
"of course" probably means that the pages are unique anyway and there is no point in storing them all. #903763 discusses HTML::HTMLDoc. I personally use <HTML>doc directly. It performs well but requires you to stick to simple HTML without CSS.	[reply]
Re^3: Finding the right PDF module by CountZero (Bishop) on Aug 17, 2011 at 07:57 UTC
I can only speak from my personal experience, but the applications I made stored the unique results of the request in a file (it were spreadsheets, but that is irrelevant for this discussion) and just returned a link to this file to the client requesting it. All the heavy lifting of making the file was done by the Perl script and the sending of the file to the client was done by the Apache server. As far as the webserver was concerned this was just a static file. I found it most efficient. Once every so often a cron job would reap all "old" files to reclaim disk space. CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James	[reply]
Re^4: Finding the right PDF module by ksublondie (Friar) on Aug 17, 2011 at 20:23 UTC
Honestly, I doubt these unique pdf's will ever be intentionally saved. Saving the files would be a waste of resources even if they were periodically cleaned up. The bulk are one-time disposable transaction reports or stock mass mailings that will be printed, mailed, and never viewed again. Even if they are later needed, the saved report will most likely be obsolete and require a re-generation anyway. However, that's not to say that I won't be saving any of them. It's just that THESE won't need to be saved.	[reply]
Re^5: Finding the right PDF module by CountZero (Bishop) on Aug 18, 2011 at 19:27 UTC
Re^3: Finding the right PDF module by ksublondie (Friar) on Aug 16, 2011 at 20:33 UTC
...the pages are unique...no point in storing them all... Exactly. I'm leaving that up to the end user.	[reply]


Welcome to the Monastery
	PerlMonks