[reportlab-users] reportlab and Zope

[Robin Becker]

In article <20020717153726.GA12191@mail.librelogiciel.com>, Jerome Alet
<alet@librelogiciel.com> writes
>On Wed, Jul 17, 2002 at 03:27:47PM +0200, kamahunda mulamba wrote:
>> I'm a new user of reportlab and I want to use this library to draw 
>> graphs in web pages generated by Zope. 
>> Can this library be used into Zope?
>
>It is possible.
>
>Look at demos/rlzope in the ReportLab package, it's a sample
>of a Zope External method which extracts datas from Zope and
>returns a PDF document in the web browser.
>
>beware: some people say that problem may arise because RL is not
>thread safe, with low volume I haven't seen any, but as always: YMMV.
>
>hth.
>
>Jerome Alet
.....
We've discussed this a couple of times. There are two known problems
that I'm aware of, first RL isn't thread safe, second if you have the
wrong combination of Zope and Python there can be leakage of
paths/modules between the Python and Zope installations (at least under
win32).

As for the thread stuff it's risky to just use RL bare. My take on this
is that as RL is a relatively heavyweight process access to it should be
done using a serialiser queue. Then threads can push jobs onto the queue
in a safe manner and choose what action the Q should take at finish.

The RL server end of the queue can then pop jobs off and run them. There
are a some possibilities, 1) the job says create this object/file in the
Zope universe or 2) it says merge with me and write stuff into my
request standard output, 3) it could also say create a string and then
hand that back to me. In each case the job would have to provide the
requisite data/settings. Type 2 above is efficient, but dangerous in
that it's hard to handle errors easily.

I did something like this before with Zope, but it's a very standard
sort of paradigm so perhaps there's someone else in Zopeworld with a
better grasp of the difficulties?
-- 
Robin Becker