* mario ruggier wrote [2005-11-04 08:18:23 +0100]:
> Thanks everyone for all the comments... just a tiny clarification, as I
> think you are all assuming Quixote

I think so too, although I still see the two as being complimentary - a
growing community in one or the other helps the other, given their common
publisher heritage.

> , while I was musing on QP, that has a different raison d'etre than
> Quixote... QP has given itself license to make specific choices about
> applications built using it.

Despite the potential controversy of an apparent fork in the road, its good
that QP arrived. You can be pretty productive quite quickly with QP, thanks
to some sensible default choices having been made for you.

The most controversial choice is that of persistence, but in my view Durus
deserves more exposure and QP is a good route for this.  ZODB and object
databases like Durus are too cool to be the principal domain of the Zope
community itself. Way too cool to be locked up...

I'm not an easy convert to the object database world -- I have ... counting
my fingers and toes here ... hmnn almost two decades of relational (Oracle,
SQL Server, a little Sybase, and these days mostly Postgres) and
non-relational (some rather ugly mainframe stuff, a home grown btree-like
scheme in Pascal, and various IBM and CA products over the years) database
experience behind me -- expressing ideas in SQL is easy enough with or
without an OR mapper.

I can think of real-world applications I would *not* put Durus
or ZODB behind, applications I've worked on in the past, so its unlikely SQL
will completely disappear from my toolkit.

But now that I've sampled the oodb Koolaid for awhile, I rather like it ;-)
and if an object database suits an application, I won't have any hesitation
in going that route.

Incidentally we had a discussion on the Durus list last month about storing a
lot of objects, the first pass was 1.8 million:

http://mail.mems-exchange.org/pipermail/durus-users/2005-October/002997.html

I got up to 5.5 million objects before running into a FreeBSD memory
constraint, one which I could have easily removed by tweaking a kernel
parameter.

http://mail.mems-exchange.org/pipermail/durus-users/2005-October/003012.html

What I discovered was that even with a large amount of data, Durus has the
potential to scale, provided you don't have all those objects in one flat
data structure like a list ;-). Still, for the example stock quote management
database I cooked up, if I really needed to keep the quotes in a database
(probably do not - there would be nothing wrong with keeping the quote
records in text files, located from a Durus index of only 10,000 symbols) I
would lean to Postgres, SQL Server, or Oracle, all of which I know employ
schemes to reduce memory usage even when there are tens of millions of rows.

I'm not at all disappointed about what I learned through the experience, in
fact it gave me a good deal of comfort knowing where the upper bounds of a
Durus-based application are likely to be, and that knowledge is confidence
building even if it describes a limit.

I suspect for a good many applications, Durus or ZODB are more than suitable
for persistent stores.

This is long-winded but I am coming to the point now - it seems to me to be
important that "QP" exists both to further promote Durus, as well as offer a
nice tight and cohesive development platform.

To me the combination of QP and Durus gives me all the best of Zope (and none
of the worst) - easy object 'publishing' on the web - with a still-simple and
easy to understand toolkit, all in Python, allowing folks to lever off what
they know and spend time writing applications.