[Zope-dev] RE: [Zope] Some tough questions about zope... (long)

[Richard Wackerbarth]

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.