On Apr 27, 11:27 pm, "BJörn Lindqvist" <[EMAIL PROTECTED]> wrote: > I think twisted is overkill for this problem. Threading, elementtree > and urllib should more than suffice. One thread polling the server for > each race with the desired polling interval. Each time some data is > treated, that thread sends a signal containing information about what > changed. The gui listens to the signal and will, if needed, update > itself with the new information. The database handler also listens to > the signal and updates the db.
So, if i understand you correctly: Assuming 8 races and we are just about to start the race 1, we would have 8 polling threads with the race 1 thread polling at faster rate than the other ones. after race 1 betting closed, could dispense with that thread, change race 2 thread to poll faster, and so on...? I had been rather stupidly thinking of just two polling threads, one for the current race and one for races not yet run... but starting out with a thread for each extant race seems simpler given there then is no need to handle the mechanics of shifting the polling of races from the omnibus slow thread to the current race fast thread. Having got my minidom parser working nicely, I'm inclined to stick with it for now while I get other parts of the problem licked into shape. However, I do take your point that it's probably overkill for this simple kind of structured, mostly numerical data and will try to find time to experiment with the elementtree approach later. No harm at all in shaving the odd second off document parse times. -- http://mail.python.org/mailman/listinfo/python-list
