in reply to Strategies for temporary image files in CGI

Here's a sound approach - drop the .gif files. Use .png files instead. PNG files were invented as a free alternative to replace GIF files as the GIF files have proprietary LZW compression algorithm.

Here's one algorithm I can think of -

Step 1 - Get most recent data from DB
Step 2 - Compute MD5 hash of data, or CRC32
Step 3 - Compare it with previous MD5 hash stored, together with timestamp
Step 4 - If hash values differ, new data found
and so on...

Here's a more efficient approach I can think of, if your database supports triggers -

Step 1 Implement database triggers on insert, delete and updates
Step 2 Update the modified flag in a user defined table, say, DATABASE_STATUS, that has two columns, modified_flag and last_modify_time.
Step 3 CGI script checks for the MODIFIED_FLAG in the database
Step 4 Generate new excel & PNG image if necessary by looking at the timestamp and modified_flag.
Step 5 Clear the modified_flag, and set the last_modify_time.


  • Comment on Re: Strategies for temporary image files in CGI

Replies are listed 'Best First'.
Re: Re: Strategies for temporary image files in CGI
by tilly (Archbishop) on Nov 23, 2003 at 00:41 UTC
    The proprietariness of gif has an expiry date. That expiry date has passed for those of us in the USA. It will be over in every country on June 20, 2004. See this timeline. Given the legal climate in Europe, I doubt that the European version was ever enforcible. (IANAL and all that.) Those two between them cover most of Perlmonks.

    Therefore the issue of not using .gif for intellectual property reasons is lessening in importance, and all things considered, I would not worry about it too much. (FWIW I am in the USA, where it expired already.)

[reply]
Re: Re: Strategies for temporary image files in CGI
by Itatsumaki (Friar) on Nov 21, 2003 at 17:05 UTC

    Excel made it remarkably easy to change from GIF to PNG formats (just changing a parameter). And the image quality is pretty much the same, so that worked well. Thanks!

    I like your first approach, since the chart data is coming from a query returning multiple records. If I read what you are suggesting correctly, I don't have to worry about time-stamps at all, just check the hash values. That would allow much longer time-to-refresh values for the files.

[reply]
      Personally I don't think the time-stamp is necessary. But your original post said there was a requirement of not generating a new image within 48 hours. The timestamp is used for that purpose. If your data is pretty static, you can certainly drop that 48 hour checking bit.

[reply]

        Indeed, data can't be refreshed more often that every 48 hours, but not all data will change in every update, so this is a superior solution.

[reply]

In Section Seekers of Perl Wisdom