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

[Paul Everitt]

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