I was thinking a lot about the proposed Zope3 web root, and the mentioned RDBMS first class citizenship.
I'd like to backup an usecase and propose a somewhat different approach ..

First of all, having the ZODB optional and mountable IMHO is a great thing, because it is not always needed, or even usable - imagine for example lots of accounting or statistical data, stored in millions of rows in a RDBMS, several years old, and presented using charts and grids. Moreover, I would and do design brand new Zope3 applications using SQL storage, not the ZODB, even when the storage is local to the filesystem (sqlite), just because I firmly believe, that the place for data is in the RDB, not in the ODB. Also because I couldn't find easy and effective enough way to get 20 objects out of 100000 pieces in an ordered set, starting with number 27897 for example, but that's another story and may be entirely my fault as I didn't care to look very hard. But I know a lot of tasks, which the ZODB is much better suited for, especially if it did had that shiny little tool, capable of not only analyzing and displaying a stored object, but also changing it - it could spare me many minutes worth of restarting and waiting Zope to boot each day. It is on my todo list, you know, I just need some spare time. And the proposed indirection analyzer tool could spare some 2 months full of curiosity and curses as I slowly made my way trough let's say about 20% of that rapidly-changing-worst-documented-in-the-world big picture (not talking about Zope2, sorry guys, but although the more I learn, the more I love Zope3, it's not easy at all).

Anyway, one of the strongest arguments against that web root in the filesystem is the Apache - why do we need Zope3 to serve files and directories out of the filesystem, and have those config files there, when we have a very sophisticated and solid tool, which does that more than fine and also a lot more, and more effectively than we can ever dream of with an interpreted language? You know, it wasn't the very next question that I asked myself, although it is so obvious, but eventually I got to it - well, why do we need Zope3 to parse HTTP requests while it generally and historically proved exists proxied behind this very tool, which is so much capable of parsing HTTP, and is also so flexible? Zope3 uses it's integrated twisted server to do everything about parsing protocols, but as I already said, we can't even dream of reaching the effectiveness of a heavy duty pure C/C++ HTTP machine which has decades of development and fine tuning behind, by using an interpreted language. And remembering the statement from it's own documentation, that Zope doesn't care much about what is in front, as long as it supplies the right object, then why not just mod_zope it ? And guess what .. There is that fundamental truth about Internet - it doesn't matter what idea just came to you, it is already there. Turns out that somebody is already doing it at http://codespeak.net/z3/modzope/ . So why not making it at least a bit more official and feature-complete? For example - capable of rendering page templates directly from the filesystem and mounting ZODBs .. Integrating with existing and proved solutions seems a lot more natural and trouble-proof, than doubling them and Apache has a lot that could be used in Zope.

Velko Ivanov
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to