win32 design pattern: COM localserver?

[Mark Hammond]

If you are implementing a COM object using win32com, then Python will 
never be unloaded from the host process, which works in your favour. 
Just have the COM object use a thread and a queue for this processing. 
The 'report' method would just stick the params and filenames in the 
queue and return immediately - your thread should stay alive and working 
away so long as the host process remains alive.  You probably need to 
deal with the face the thread will be unexpectedly terminated when the 
host process terminates or add a new method designed explicitly to block 
the host process until everything is complete - the host program would 
then call this method just before it terminates.

Also note there is a python-win32 at python.org mailing list where you 
might get better or more advice...

Cheers,

Mark


On 8/12/2010 8:03 PM, kirby.urner at gmail.com wrote:
> Greetings gurus.
>
> I'm faced with the challenge of having a single-threaded proprietary
> Win32
> language wanting to do multiple calls against a Python COM object.
>
> Something like...
>
> loObj = CREATEOBJECT("map_maker")
> loObj.report( params, filename)
>
> do while .True.
>    yadda yadda
> enddo
>
> RETURN
>
> I.e. the client program continues execution while loObj churns away
> somewhere doing work in Python, say accessing a MySQL database
> and building a map, embedding it in a PDF.
>
> Am I right that the COM object will need to "serve forever" i.e. be
> built around some non-terminating loop?  Will the client's call then
> spawn a process or thread that continues until finished?
>
> All it has to do is leave a file on disk somewhere, then die.  But
> the client can't be kept on the hook until that's all done.
>
> I've had good luck doing an InProcess COM object the generates
> a PDF from ReportLab.  But this "stay alive while returning control
> to the client" challenge looks like it might be a job for sockets?
>
> Gee I hope not.
>
> Quick links to favorite blog articles will give me a sense of the
> ballpark...  Any clues welcome.  Yes, I have the Win32 book from
> O'Reilly.
>
> Kirby
>
> PS:  my thanks to Ethan Furman for performing maintenance and
> upgrades on his dbf module on PyPI.  The FoxPro gods thank you.
> http://pypi.python.org/pypi/dbf/0.88.16
>
> PPS:  some thoughts about IronPython filed here, after trying to
> catch up some, sorry about my formatting, here too.
> http://mail.python.org/pipermail/edu-sig/2010-December/010138.html
>