App implementation help needed

Joseph A Knapka jknapka at earthlink.net
Mon Jul 15 21:37:10 EDT 2002


Dave Swegen wrote:
> 
> I'm currently designing the second part of a little pet project of mine,
> and run into a wall regarding how to proceed, and would much appreciate
> some assitance in figuring out in which direction I should go.
> 
> The setup is as follows:
> 
> A daemon has a queue of times when it should perform an action that
> involves fetching some data from a web site.
> 
> These times, and associated data (which end up customising the URL), is
> to be provided by users via a web interface.
> 
> The user provided events, as well as some user data (username, password)
> need to be stored.
> 
> The program will in the first instance be running on Linux, but if for
> no extra cost I can make it run on other platforms that would be nice
> (but not at the cost of simplicity).
> 
> All pretty simple stuff in itself. My problem is how to tie together the
> different parts (web interface, updating queues, calling a certain function
> at a certain time with certain user provided data).
> 
> Are threads the best/easiest way to achieve this? Are fork()s sufficient?
> Or would having the web interface based on asyncore allow me to avoid
> using threads/forking entirely?
> 
> Is using the Queue module appropriate, or would a list be sufficient?
> 
> Would using sleep(1) in a loop be sufficient (I need second precision,
> so cron is not really an option), or would sched be more appropriate?
> 
> I don't want to use a full DB, so should I go with pickling or anydbm?
> 
> So, lots of questions, probably not enough background information, and
> somebody who is rather overwhelmed by the options avaliable.
> 
> I'm hoping to keep this as simple as possible, so please, be gentle :)
> 
> Any help much appreciated.

If I were doing this, and I wanted to keep it extremely simple, I
would do it like this:

(0) Create a special directory, /workdir. This is a blessed place
that's used for communication between the web interface and the
daemon.

(1) The web interface: a simple Python CGI script that essentially
does this (forgive the silly fn names; I don't remember how
to spell the file operations at present):

def handleFormData():
  queEntries = processFormData()

  tempfile = makeATemporaryFilename()

  f = open(tempfile,'w')

  f.write(queEntries) # Maybe pickle, but no need if the queue
  # entries are simple things that can be eval'd.

  f.close()

  moveTempfileToWorkdir()

(2) The queue handler: a simple Python program that maintains
the event list:

def mainLoop():
   sleep(for a little while) # Maybe use socket.select() if you
   # want really brief sleeps.

   processEvents() # Kick off any events that have expired.

   checkWorkDir()

def checkWorkDir():

   files = listFilesInWorkdirByCreationDate()
   for file in files:
      qes = readQueueEntriesFrom(file)
      addToEventList(qes)
      delete(file)

It's important that we create the /workdir entries as
temp files elsewhere and then move them to /workdir;
that way the daemon never sees a half-written work file.

You could do checkWorkDir() and processEvents() in separate
threads, but that would be less simple!

The communication mechanism (files in a blessed work
directory) is lame, but should work pretty much anywhere.
Porting such a thing to EvilEmpireOS should be a snap
(just change the work directory name).

I'll be interested to see other proposals.

Cheers,

-- Joe



More information about the Python-list mailing list