Re: automated file removal / cache clearing

[drieux]

On Thursday, Aug 28, 2003, at 14:16 US/Pacific, [EMAIL PROTECTED] 
wrote:
[..]
I am glad someone put this into easily understood terms,
I was thinking the same thing and couldn't come up with a
compact way of saying it :-)...
Think about where I live - there are so few chances for
mathematicians to sit around and be pedantic - but every
now and then, reminding folks to DO Algorithm Analysis
is one of those rare opportunities. Or should I say
	Algorithm Analysis - Not Your Grandfather's AA???

But the real issue is in the 'design' of the OP's original
CGI code that 'wandered' him into 'caching' information in
a bunch of 'files' some of which will need to be cleaned up.
Octavian's Proposal has 'merit' when the thing that one
is 'caching' into a file needs to be unique, and is not
as 'dynamic' and/or 'session specific' as the OP's original proposal.
Allow me to illustrate the argument.

I have a web-tool that I use to create 'configuration files'
for a daemon. One CAN create those config files, 'the old
fashion way' but simply sitting there and using 'vi' and
typing... But that can be a bit annoying. So the web tool
walks the user through the process. The Basic Format is
        Header_section
                several basic header fields
        Element_section
                serveral basic element fields
With the simple caveat that there can only be one header,
but many elements. My solution was to use the SDBM_file and
write the appropriate marshelling and unmarshelling
stuff that will [add|delete|update] 'header|elements'.
All I need is a 'SID' - Session ID - so I know which
of the temp files IS the DB I am looking for. No SID,
No DB File, No Play.
This of course allows me to have different 'pages' that
deal with the basic 'operations'
        edit header
        add element
        delete element
        edit element
        duplicate element
        Save Configuration
        Abort Configuration
        Show Configuration
And the whole 'configuration file' stays in the 'cache'
until we get to the Save or Abort sequence. The problem
of course is that if the PRIMATE does not follow the
rules, and Abort Out, there will be this skanky little
SDBM_File hanging out in the temp directory. There are
several ways of solving this, the 'cron job' is one way,
or one can do 'man periodic' on BSD systems and look
at installing a 'periodic cleaner' for your specific package...
But remember this is a problem that will occur only
when folks are creating configuration files, which is
not a 'regular' event, but a very low volume sequence
in the overall project.
I had thought about having the 'save.cgi' or the 'abort.cgi'
do the very thing of,
        OK, we did ours, what about checking
                for any marooned config file cache's.
But the best that I could come up with was that I would
want to be 'safer' and know that the cache was older
than a day, and not merely that the primate had decided
to run off to
        a. the bathroom
        b. a smoke break
        c. feeding time
        d. an arcane argument in a technical mailing/newsgroup
        e. skylarking in a happier universe.
At which point the, 'oh dear....' I do not have enough
gurantee to even do the 'cron job' approach... Some folks
can get distracted for arbitrarily long amounts of time.
So in my case, it was just simpler to leave those problems
to the sort of traditional 'unix' solution of 'clearing out /tmp'
when we reboot...
The core problem the OP still needs to work out is:

        so why are you caching in little files
                that can be abandoned/marooned on the file system?


ciao
drieux
---

--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]