Don't do a tightly coupled system. Pass RTF files, CSV files or whatever from the Linux side to the Win32 side, and have a Perl program monitor the drop directory. Then import the data into Office, munge it and spit it out again.

Another (bad) idea would be to push over actual Perl code to be executed instead of data files, but if you already look in that direction, consider a database to handle outstanding jobs etc. You will have to have Perl code on the Win32 machine in any way, and I would try to avoid any fancy RPC scheme in favour of file based transfer or DB based transfer, where the advantages and disadvantages of both are to be weighed.

You obviously haven't done much research in the direction, so here are some dire warnings:

1. Office is single user. If you have more than one process trying to automate things, you are asking for much trouble.
2. You might be well better off to use SpreadSheet::WriteExcel or simply distributing .pdf files or csv files instead of trying to produce them via OLE.

Many thanks Corion. We greatly respect your postings.

If you could, could you explain your suggestion, "Don't do a tightly coupled system"??

Could you comment on the suggestion to use SOAP::Lite (below)?

Thank you very much for your advice and wisdom!

A tightly coupled system is, at least for this discussion, a system where the whole process comes to an immediate halt once a single component fails. For example, with XMLRPC/SOAP, as soon as one of the two computers becomes unavailable, the other one can't work anymore, and there is no method of manual intervention to fix it. Tight coupling has the advangtage of close process control in the sense that you get an immediate feedback of the next system whether and when your data was processed.

If you do a loosely coupled system, where you pass the data on to the next program by mail, file or database, you lose this close control, but you gain buffering. Mails, files or database entries can stack up without problems, even if the system behind it fails. If the producing system fails, the production can be manually maintained by manually producing the input. If the consuming system fails, you can either wait and keep the input piling up or manually transfer the input to a second backup machine, which then produces the output. There is more possibility of human intervention in loosely coupled systems.

I have never personally used SOAP::Lite, as I am no great fan of RPC over port 80. If interactivity and immediate response is not important to your requests, go the loosely coupled route. It makes for easier testing, easier error recovery and easier monitoring of the whole system.