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 large
(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 help.

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
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to