Hi Mathias, The main thing that will need to be done is to convert between various formats using OO as the conversion engine, the problem is that with the requirements it can be that we will need to be running conversions concurrently. Conversion is one of the services offered up by a server in a client server architecture (it is not a webserver in the current version).
Conversions are started by a queue manager and monitored for progress by a separate monitoring process. So I am worried also about stuff like being able to increase memory available to OO as need be... Cheers, Bryan Rasmussen On Jan 11, 2008 12:55 PM, Mathias Bauer <[EMAIL PROTECTED]> wrote: > Hi Bryan, > > > bryan rasmussen wrote: > > > Hi, > > > > I have an application where I need to automate MS Office to do > > rendering of MS Office documents, for some of the reasons outlined in > > this knowledgebase document from MS > > (http://support.microsoft.com/kb/257757) I think OO would be > > preferable for this, my specific worries involve: > > > > 1. Office Applications assume that they are being run under an > > interactive desktop, and may in some circumstances need to be made > > visible for certain Automation functions to work properly. If an > > unexpected error occurs, or an unspecified parameter is needed to > > complete a function, Office is designed to prompt the user with a > > modal dialog box that asks the user what they want to do. A modal > > dialog box on a non-interactive desktop cannot be dismissed, which > > causes that thread to stop responding (hang) indefinitely. Although > > certain coding practices can help reduce the likelihood of this > > occurring, they cannot prevent it entirely. > > > > 2.(Office Applications ) offer little scalability as a server-side > > solution, and have fixed limits to important elements, such as memory, > > which cannot be changed through configuration. More importantly, they > > use global resources (such as memory mapped files, global add-ins or > > templates, and shared Automation servers), which can limit the number > > of instances that can run concurrently and lead to race conditions if > > they are configured in a multi-client environment. > > > > > > Since I need to automate without user interactivity and with the need > > to run a lot of these instances concurrently I have the imperfectly > > formed opinion that I would like to have confirmed, with hopefully > > some documentation that shows the correctness of the opinion, that > > opinion is that OO would be preferable to this task. Anyone know if > > that is correct or incorrect? > > Without knowing which APIs you will use nobody can give you any promises > about that, only a general statement that basically OOo API calls don't > need a visible document window or user interaction. > > Ciao, > Mathias > > -- > Mathias Bauer (mba) - Project Lead OpenOffice.org Writer > OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS > Please don't reply to "[EMAIL PROTECTED]". > I use it for the OOo lists and only rarely read other mails sent to it. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
