RE: [Zope] Some tough questions about zope... (long)
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 that fully implements the HTTP spec can talk to Zope. Skip is also using XML-RPC to get to Zope via Perl. Jim has spent some time thinking about adding XML-RPC support to the publishing system. Zope supports "Netscape Publishing", aka HTTP PUT. Thus you can sit in Netscape Composer and blast a whole directory into Zope in one fell swoop. Let's see, some other choices. When ZServer gets a little farther along you can use FTP. When we release the WebDAV support in Zope, you'll be able to use IE5, FrontPage 2000, and a number of other products to move information into and out of Zope. Until then you can use the command line WebDAV clients like sitecopy.
I certainly don't want to reinvent wheels. 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. Let's see, you'd also lose the benefits of the Zope cache. You'd obviously lose all concept of versioning and undo. 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 ...
Mentally, I look at a file system as an implementation of a database which has structured keys and is efficient at supplying large "results" (the file) from the (path) key.
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. --Paul
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.
participants (2)
-
Paul Everitt -
Richard Wackerbarth