<p><font face="Arial" size="2">Event loops everywhere…</font>
</p>
<p><font face="Arial" size="2">I've inherited a small python utility
that we use for system monitoring. It uses CORBA to capture event
traffic and report some status (using CORBA EventService registration,
status events) via a Tkinter GUI. The app is run by the Tk
"mainloop" and at frequent intervals calls the orb's perform_work()
method to process events. This approach of calling </font><font face="Arial" size="2">frequently </font><font face="Arial" size="2">into the ORB
seems to work OK and does not appear to hold up the GUI. </font></p>
<p><font face="Arial" size="2">I need to update the app so that it can
handle the event service disappearing and re-appearing (i.e. Make it a
bit more robust to handle the remote end starting/stopping). We want this tool to run continuously while the
system we monitor is started and stopped. It needs to reconnect when
the system comes up and not crash when the system shuts down.</font></p>
<p><font face="Arial" size="2">I would also like to take the
opportunity to make the CORBA related code somewhat more generic (not
bound to the Tk mainloop) so I can use it for other tools which will
not have a GUI and hence no TK mainloop. The Twisted framework seems
ideal - I am familiar with Twisted, I think I could use it's
task.LoopingCall to perform the re-connections and the perform_work
call, the Tkinter mainloop can be integrated into the Twisted reactor
etc. Many of our apps are Twisted based so having a common code base is
plus for future maintenance too.</font></p>
<p><font face="Arial" size="2">There is no point pursuing this approach
if it is well known that the ORB does not work within the reactor. So
to possibly save me some prototyping time, I was wondering if anyone
had (or heard of) any experience's of running the ORB within the
reactor? Specifically I'm using omniOrbPy and the omniOrb ORB.</font></p>
<p><font face="Arial" size="2">Regards,</font>
<br><font face="Arial" size="2">Chris</font>
</p>