in reply to Graph::Map and a Browser (no server side storing)

As a slight aside, I'm attempting to do this as it will save on IO, and I wont have to write a scavange routine to trash the old graphs.

As a counter-point to the desire to write a scavange routine to clean up old graph image files, I would direct your attention to aspects of temporary file handling described previously by myself here - In particular I would direct your attention to the File::Temp module which provides methods for creating and working with temporary files as anonymous STDIO streams which are not stored beyond the life of the file handle.

This approach, while still encompassing the aspect of IO hits, would allow you to generate your temporary image files without the need for an expensive clean up routine. Mind you though, if the site is only ever going to serve a small audience, is the IO performance hit really going to impact your application or system load greatly?

 

  • Comment on Re: Graph::Map and a Browser (no server side storing)

Replies are listed 'Best First'.
Re: Re: Graph::Map and a Browser (no server side storing)
by Ryszard (Priest) on Apr 02, 2002 at 06:06 UTC
    I've got a couple of thoughts here:
    1. Create something now on a small load site so I have the "theory" down, and can expand onto a larger volume site
    2. Disparity - The web app its pretty much all encompased within the CGI::Application framework, and having a seperate script kicking around loosens the bundle slightly.
    Thanks for the point in "another" direction.. sometimes I just sit here trying to think around the problem and all I end up with HUA syndrome, and cant see the forest for the trees.
      With regard to disparity, while I still think that your best method for handling temporary files will be through File::Temp, there is another option. If you are looking for something more permanent than anonymous STDIO streams and filehandle scope, for example if you wanted to optimise with some server-side caching (for which I would recommend Cache::Cache), you may want to explore the teardown method from CGI::Application.

      This method is called upon termination of the execution thread and allows for clean-up code to easily be incorporated into the CGI::Application framework. Most commonly, I make use of this method for the closure of file handles and database connections prior to script termination.