On Jul 14, 11:16 pm, Larry Bates <[EMAIL PROTECTED]> wrote: > Vinay, > > Thanks for your detailed explanation, but IMHO your suggested solution is > almost > the opposite (right idea wrong direction) of what I'm looking for. > Hypothetical > setup: > > application1 - SocketHandlerloggingturned on > application2 - SocketHandlerloggingturned on > application3 - SocketHandlerloggingturned on > . > . > . > applicationN > > monitoring app - ThreadingTCPServer target that Allows user to connect to ANY > running application and to view the real-time log messages. After monitoring, > it should be able to disconnect and connect to another application... The > clients (application1..N) never stop sending and don't ever send anything > short > to disconnect themselves from the monitoring application. The disconnect/ > reconnect is done at the monitoring app end based on input from the user. I > think each one would beloggingto a different port, but I never really quite > got that far. Perhaps there is some other way that I'm missing. It seems > like > this is something that might be able to be "generalized" into a robust > monitoring application for an arbitrary number of asynchronously running > applications. > > Each application's real-time log might be reached by clicking on a tab, menu, > etc.
Here's how I see it: the socket server listens, and receives logging events from numerous applications in real time. If the server is configured to monitor app1, then it quietly discards (or doesn't show in the UI) all events from other apps - it only collects/shows events from app1. When you click on a tab/menu/whatever to switch to monitoring app2, then this information is used to tell the server to discard (or not show) events from all apps except app2. You would of course need to ensure the communication between UI thread and server thread were done in a thread-safe manner. > As to the difficulty, I might just have a mental block but two modules that > I've > had a real hard time getting my mind wrapped around is yourLoggingand Twisted. > They both have a multitude of options/ways to be used and not very many > working > examples to work from. Might be a chance to make some money on a book. If it > was full of examples, I'd purchase it. > But there are numerous examples in the logging docs - the script you quoted as having put together after several hours of Googling is pretty much the same as the (working) version in the logging docs! If you have reviewed the logging docs and find them lacking examples, please provide more detail about the kind of examples you think are missing. And I can't speak for Twisted, but it does a lot more than logging - and I don't think there's enough complexity in Python logging to warrant a paid-for book. (No doubt people will tell me if they disagree!) Best regards, Vinay Sajip -- http://mail.python.org/mailman/listinfo/python-list
