Tino, *snip*
I see many people complaing about the fact of zope using not plain files for objects. And any time I'm asking why zope should? Is there any RDBMS out there which stores its tuples in separate files? Nope! In fact, it an RDBMS use this, I'll not use it :-) It is just that Zope is a bit ahead of its times and people have difficulty accepting it. Daniel's original mail was about how to "sell" Zope, which is why I pointed this out because, believe me, I've had to fight this fight about why I chose Zope, quite a few times.
The following is slightly off-topic: ZODB's exposition via Zope that mimicks a filesystem is Zope's biggest advantage along with acquisition, IMO. However, when "selling" Zope, this is also its biggest disadvantage because people tend to associate hierarchical object database with outdated technology. Majority of us who learned programming after late 80's may not think excitedly about hierarchical or network databases. (Talk about being hypocrites, most of us support XML datasets which are nothing but hierarchical). Because Zope so effortlessly mimicks filesystem, people *perceive* it to support all operations you can do with a file system. I do too - old habits die hard :-) Often I see myself wishing for "Oh god, Zope makes all these things so easy. If only I had some kind of locking/tagging/versioning from which I can easily restore objects..." Another issue is people usually want to put data into DBs from which you can easily extract it, do batch updates etc. Mass updation in Zope is still not as straight forward (meaning, can someone knowing only HTML and Javascript figure it out looking at Google) like in SQL "update xyz set x=y where z=a". Yes it can easily be done using a Python script, but many newcomers to Zope may not know Python. [This has been my fondest wish for 2 years] Perhaps Zope Corporation should hire some designers and make very colorful ads on techie/business magazines about how Zope supports RAD, inexpensive hardware, makes different development groups work in harmony (eg: SQL folks and HTML folks can easily work without stepping on each others toes), cross-platform, open standards like DAV, FTP, XML-RPC...
What could be handy, however, would be a cvs pserver implementation for ZServer to ease the use of standard programming workflow without resort to the ZMI all the time.
Amen. Best regards S Babu http://vsbabu.org/