On Tue, Jan 19, 2010 at 7:03 PM, Mathias Bauer <[email protected]> wrote:
>> I think OOo should not even broadcast events for these documents. They >> are implementation details subject to change. Components have no >> business dealing with them. > > What is an "implementation detail" might be in the eye of the beholder. > A temporary document created while doing mail merge can be seen as > "implementation detail", but not if there is an extension that wants to > hook into the handling of database fields in general, like e.g. Stampit. > I know for sure that we would break that extension by not broadcasting > the events for documents created while doing mail merge. How does Stampit prevent OOo from disposing the documents behind its back? My experience so far has been that even if I wanted to do something useful with the temporary mail merge documents, I couldn't, because OOo concurrently disposes them. Another big problem I have is performance. Right now I test the URL of the document and ignore it when it's in /tmp (Doesn't work with 3.2, unfortunately). Even with this simple test, mail merge performance drops significantly. I need to determine as quickly as possible that a document is from a mail merge process. Otherwise mail merge performance becomes intolerable when you do several 100 instances. After all, our ex-Word users already consider OOo's mail merge performance (several orders of magnitude slower than Word's) intolerable even without an extra extension slowing it down further. Matthias --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
