What would be the best way to run python client in the background

[gel]

Tim Golden wrote:

> | > [gel]
> | >
> | > | I have written a python client server app [...]
> | > | I want to run the client end of the app more or less invisibly
> | > | (no console) on the XP clients when ever a users logs on.
>
> While this isn't answering the question you first
> asked, might I suggest an alternative approach?
> Obviously, I'm working from no more than the sketch
> you gave of your app and its requirements, but might
> it be worth turning the problem on its head, and
> using WMI?
>
> Advantages:
>
> 1) WMI will -- almost certainly -- already be running on your
> target machines. No need to install your own service.
>
> 2) WMI has a fair range of mechanisms for determining
> what processes are starting, stopping, etc. and for
> manipulating them remotely.
>
> 3) You can, at least in theory, access any number of machines
> from a central server, and with a bit of judicious threading
> or looping, you should be able to generate a fair bit of resilience
> to machine dropouts etc.
>
> Disadvantages:
>
> 1) What you're doing may be far more complex than you've
> outlined, requiring a local service per target machine
> for other reasons.
>
> 2) You may have already invested some amount of time and
> effort in developing an app which does what you want.
>
> 3) I may have entirely misunderstood what you're trying
> to do in any case.
>
> If you're interested and want a code sample, let me know.
> If you're not, that's fine.
>
> TJG
>
Yes Tim I would be interested in seeing a code sample of how you would
approach this using a central server using wmi.

I am using wmi at the moment too, but on the client side, then pyro to
keep a central record of what was being run where.  So the client side
watches for starting praocesses, when one is found it checks the pyro
object on the server to see if the process is one that is being watched
and if it is, check to see if the allowed limit of PCs running that
process has ben reached.  If the limit has not been reached the client
marks the pyro object on the server to indicate that another PC is
running that piece of software.  If the limit has been reached the
client side kills the process and pops a dialogue box up stating that
there are no more licences available for that piece of software and to
try again later.  The reverse happens when a process is stopped.  If
the process is one that is being watched  and that client has a licence
book out for that software (checked with the MAC address) the number of
PCs running that pieces of software, which is stored in the pyro object
on the server decreased by one.

The thing that springs to mind with using a method where a central
server is using wmi, is the question of  if a lot of polling of the
remote client would be needed to know when a new process starts or
stops and if this would be heavy on the network and server?