[Zope-dev] RE: [Zope] Some tough questions about zope... (long)
Richard Wackerbarth
rkw@dataplex.net
Fri, 12 Mar 1999 09:43:12 -0600 (CST)
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.