Those suggestions are great. For something like log analysis, there's no problem either reading in log file tails ever so often or queuing up a single thread to give more real-time access. I think I'm leaning towards a more real-time view, but I might take the tail option if it codes easier.
On the topic of threads, though, this does open a pile of other "running behind a Web server" sort of operations: * To keep a db of user authentication data in an SQLite db, users will need some level of real-time response to logins * To keep a db of, say, a discussion forum, user posts will need to be written and made available in realish-time * To update Web pages dynamically with information populated from a user's preference or users' usage patterns, the page will need to be generated in real time And each of these interactions with the server will occur with different user sessions in different threads. Can SQLite be used to build applications that do the operations above? Do I need to do some single-thread queue structure for each approach? I'd love some guiding thoughts on these things to help understand how to really approach the problem. Thanks! -- David ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
