GUI frontend IPC question

[Don Garrett]

  One very common and portable way to solve this problem is to use
network connections to the loopback address for IPC. 

  This has the advantages that your front end is truely a seperate
process
and can hang, die or be killed without affecting your primary
application.
It also means that your front end and primary server can (if needed) be
written in different languages, or run in different environments. It
also
means that it's very simple to allow your front end to run on a remote
machine,
or allow remote connections.

  The disadvantage is that you have deal with serializing and
transporting
all the relevant data, instead of just sharing the data structures
directly. Also
there is a strong tendancy for the front end to log behind the actual
state of
the application a little.

Campbell wrote:
> 
> Hello,
> 
> Again, because I'm working in Python, my own design issues become
> on-topic. :)
> 
> I have an app servicing up to 120 'clients' at one time.  I would like
> to make a gui which will display current status of each of the ports
> (idle, active), and some other information.
> 
> I originally made this gui a part of the server .py file, but wxPython
> takes a chunk of time out of my 'wait for event' loop (while it
> processes windows events), which then cannot respond to incoming events
> fast enough.  Creating the GUI as another application is easy, but how
> will the front end know what the state of the actual application is?
> 
> So it all boils down to 'what does IPC look like and what options do I
> have', I guess.  Every program I have written before now, had both the
> display and the inner core, both in one process, so this is very new to
> me.
> 
> Is there anyone who could help me, who would take time to do so?
> 
> Thank you for reading,
> 
> Campbell.

--
Don Garrett                                   http://www.bgb.cc/garrett/
BGB Consulting                                            garrett at bgb.cc