Matthias B. wrote:

> 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.

It doesn't, it deals with the situation as described. Choose one of the
three options and you won't be hit by disposed documents.

> 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.

I agree that we must find a way to deal with that - I just wanted to
point out that not sending out events isn't the right way.

Regards,
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]

Reply via email to