Thanks for your comments. I respond below. On Fri, 12 Mar 1999, Paul Everitt wrote:
Richard wrote:
Paul wrote:
We put them in the database. The 3 Mb Zope binaries are served out of the database, the PDF files are served out of the database. This works so well I don't even think about it any more.
Would you address the "to be uploaded" aspect. Unfortunately, from the Zope POV, not all information formatters are written on Python.
Zope currently speaks HTTP. Any programming language [...] I can certainly create a wrapper to import the data. The question is "Is that a good idea?"
I certainly don't want to reinvent wheels. Perhaps I am unclear here. The program which generates the file is not my program. I would have to use some "wrapper" to import the file.
As a result, I need to do
automatic dynamic replacement of content. "Including" a file which has been generated by the external program is certainly easier probably more efficient than generating the file, importing a copy into the database, and serving it from there.
It might appear that way, but there are other points of view as well. Do you re-read the file on every request to re-parse it, the way PHP does? If you cache the contents, you'll still have to stat the file on every request, as well as any subdocument.
The files that I have in mind do not need parsing. They are terminal data. The files are also used by "other" (non-http browser) applications. In fact, many of the files need to be available, but will never be accessed before they are replaced.
Let's see, you'd also lose the benefits of the Zope cache. You'd obviously lose all concept of versioning and undo.
IMHO, these are the very reasons that I do NOT want them in the Zope database. Streaming a 10MB movie through a cache accomplishes nothing but flushing the "good stuff" from the cache. Versioning is not a concern. I handle that externally on the input side of the generating program.
Transactions will no longer work. Unless you invented some file-based meta information, you wouldn't be able to have properties or assign security or ...
For what I have in mind, those acpects can be handled within the Zope database. I don't "break out" until I am down to the point of publishing a read-only piece of text.
Sure, it can do that. Can it do any of the other things the Zope database does? I understand that integrating filesystem information is appealing, but it certainly comes at both a feature and performance cost.
If this is acceptible, then go for it. It should be pretty easy to write a "Disk Folder" that integrates a directory on the filesystem.
That is what I had in mind. I would propose creating a Directory Folder-ish object type and a File Document-ish object type.