Hello,
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.
Regards,
Velko Ivanov
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
