Am 28.06.2010, 17:52 Uhr, schrieb Alan Runyan <>:

> I have similar feelings as Matthias.
>   - We could use something similar to the Apache incubation process.


I think in general the library should be rather flexible. I.e. (minor)  
things can be deprecated and removed rather fast. I'd also like to be able  
to make non-backwards compatible releases. We don't want to support legacy  
apis and code forever. People relying on the old behaviour are forced to  
upgrade their code or they'll have to stick with the old version. This  
means we can focus less on maintaining compatibility and more on the real  

What are your takes on this? Do you prefer a more stable approach?

>   - We should come up with a list of criteria which we want this
> complete package to achieve. I believe everyone feels that the
> Standalone ZODB package is simply not enough to build a sophisticated
> Real World application.  So we need to outline  what are the min.  
> features
> of such an aggregation.

Yes. We should probably should start by naming a few "core" things which  
most applications will need. Here are a few that popped in my head:

- indexing (full-text, fields, keywords, spatial, ...).
- querying (auto-generate indices, ...)
- maintenance (packing, error recovery, zeo administration, btrees  
validity checking, ...)
- gui browser to inspect database
- profiling tools (finding hotspots, visualizing problematic parts of your  
application, find objects consuming most space, ...)
- standard way to hook invalidations/registrations to get MVC-like  

That's already a lot. And probably still a lot missing. We might restrict  
us to less than this. If there are many contributors, we can certainly  
extend the list.

> This is a huge project.  So I completely understand the hesitation to
> invest into something so daunting.  Maybe the beginning is to blog and
> talk about the packages that DO work and get confirmation that the
> authors are still interested in maintaining these packages.

Yes, see my other post. I'll start with gathering a list of all packages  
and useful snippets which I can find on the web. I'll do a rough  
categorization and then send it here so you guys can give input on it  
(e.g. by adding your own experience).

>> I'm sure the ZODB documentation project
>> ( would gladly accept a contribution
>> towards clarifying what current best practice is for catalogs in ZODB.
> Yes.  If you are interested in sharing what packages you are using in
> production.  Let me know.  I will give you access and you can post blog
> entries on zodbdocs.  No one has taken me up on the offer.  I would  
> really
> like to see others contribute with their ZODB experiences.

I don't have any money to donate to the doc project, but I can provide a  
small article here and there. E.g. I can write about my experience with  
transactions and data managers/commit hooks/synchronizers.

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to