Jim Fulton wrote:
Shane Hathaway wrote:
> A pull strategy will be efficient for a lot more people.
I don't know what you mean by this.
I mean that the new strategy of sending open files to the publisher,
which I call a pull strategy, will work better than pushing to temporary
files. Which is why you did it. ;-)
The idea is this: run a thread whose only responsibility is to stream
image and file data out of the object database to browsers. The
thread will maintain a permanently open database connection. Other
threads will send open HTTP connections to this thread, asking it to
finish the response. The special thread will get the binary data from
the database using its own connection, which would play well with the
ZODB cache, since we'd only ever have one copy of the image/file data
in memory at a time. Contrast this with Zope 2's image and file
serving, which loads image/file data into arbitrary database
connections and immediately evicts them from the cache. It seems like
having a special connection just for serving images/files would be a
lot more efficient, especially when concurrency is high.
This sounds too complicated to me.
Well, ok. It seems easy to me. But you're the boss.
Have you followed the ZODB blob work?
I think this will provide great benefits for people who choose to store
(megabytes, not gigabytes or terabytes) files in the database. I think the
people working on it could use some help finishing it, if you'd like to
Ok. I just finished a big project and now I'm considering what to do
next, so I'll put that on my list. Thanks.
Zope3-dev mailing list