On Apr 27, 10:05 pm, "Eric Wertman" <[EMAIL PROTECTED]> wrote: > HI, that does look like a lot of fun... You might consider breaking > that into 2 separate programs. Write one that's threaded to keep a db > updated properly, and write a completely separate one to handle > displaying data from your db. This would allow you to later change or > add a web interface without having to muck with the code that handles > data.
Thanks for the good point. It certainly is a lot of 'fun'. One of those jobs which at first looks easy (XML, very simple to parse data), but a few gotchas in the real-time nature of the beast. After thinking about your idea more, I am sure this decoupling of functions and making everything DB-centric can simplify a lot of issues. I quite like the idea of persisting pickled or YAML data along with the raw XML (for archival purposes + occurs to me I might be able to do something with XSLT to get it directly into screen viewable form without too much work) to a DB and then having a client program which queries most recent time-stamped data for display. A further complication is that at a later point, I will want to do real-time time series prediction on all this data (viz. predicting actual starting prices at post time x minutes in the future). Assuming I can quickly (enough) retrieve the relevant last n tote data samples from the database in order to do this, then it will indeed be much simpler to make things much more DB-centric... as opposed to maintaining all this state/history in program data structures and updating it in real time. -- http://mail.python.org/mailman/listinfo/python-list
