[ZODB-Dev] make ZODB as small and compact as expected

Jürgen Herrmann Juergen.Herrmann at XLhost.de
Mon Jul 22 23:48:07 CEST 2013


Am 22.07.2013 13:27, schrieb Jim Fulton:
> On Sun, Jul 21, 2013 at 12:12 AM, Christian Tismer 
> <tismer at stackless.com> wrote:
>> This is my last emission for tonight.
>> 
>> I would be using ZODB as a nice little package if it was one.
>> 
>> There should be nothing else but
>> 
>>     ZODB.<some_package>
>> 
>> Instead, there is
>> 
>>     BTrees
>>     persistent
>>     transaction
>>     zc.lockfile
>>     zc.zlibstorage
>>     ZConfig
>>     zdaemon
>>     ZEO
>>     ZODB
>>     ZODB3   (zlibstorage)
>>     zope.interface
>> 
>> and what I might have forgotton.
>> 
>> Exception:
>> There is also
>>     zodbpickle
>> which I think is very usefull and general-purpose, and I wan to keep 
>> it,
>> also I will try to push it into standard CPython.
>> 
>> So, while all the packages are not really large, there are too many
>> namespaces
>> touched, and things like "Zope Enterprize Objects" are not meant to be 
>> here
>> as open source pretending modules which the user never asked for.
> 
> Despite it's tech-bubblishish acronym expansion, which
> few people are aware of, ZEO is the standard client-server
> component of ZODB, is widely used, and is certainly open source.
> 
> 
>> I think these things could be re-packed into a common namespace
>> and be made simpler.
> 
> If ZODB had been born much later, it would certainly have used
> a namespace package.  Now, it would be fairly disruptive to change
> it.
> 
>> Even zope.interface could be removed from
>> this intended-to-be user-friendly simple package.
> 
> I don't understand what you're saying.  It's a dependency
> if ZODB.
> 
>> So while the amount of code is astonishingly small, the amount of
>> abstraction layering tells the reader that this was never really meant 
>> to
>> be small.
>> 
>> And this makes average, simple-minded users like me shy away and go
>> back to simpler modules like Durus.
>> 
>> But the latter has serious other pitfalls, which made me want to 
>> re-package
>> ZODB into something small, pretty, tool-ish, versatile thing for the 
>> pocket.
>> 
>> Actually I'm trying to re-map ZOPE to the simplistic Durus interface,
>> without its short-comings and lack of support.
>> I think a successfully down-scaled, isolated package with ZODB's
>> great implementation, but a more user-oriented interface would
>> help ZODB a lot to get widely accepted and incorporated into very
>> many projects.
>> Right now people are just too much concerned of implicit complication 
>> which
>> actually does not exist.
>> 
>> I volunteer to start such a project. Proposing the name "david", as 
>> opposed
>> to "goliath".
> 
> ZODB is an old project that has accumulated some cruft over the years,
> however:
> 
> - I've tried to simplify it and, with the exception of ZEO,
>   I think it's pretty straightforward.
> 
> - ZODB is used by a lot of people with varying
>   needs and tastes.  The fact that it is pretty modular has
>   allowed a lot of useful customizations.
> 
> - I'm pretty happy with the layered storage architecture.
> 
> - With modern package installation tools like buildout and pip,
>   having lots of dependencies shouldn't be a problem.
>   ZODB uses lots of packages that have uses outside of ZODB.
>   I consider this a strength, not a weakness.
> 
>   Honestly, I have no interest in catering to users who don't use
>   buildout, or pip, or easy_install.
> 
> - The biggest thing ZODB needs right now is documentation.
>   Unfortunately, this isn't easy. There is zodb.org,
>   but much better documentation is needed.

Very much agreed. The most important thing to mention here is IMO
the use of virtualenv which keeps your python installation's
site packages clean. I don't mind if a certain package I need
pulls in any number of dependencies, as the are resolved
automagiaclly. @Chris: Maybe you could explain a bit more, why that
bothers you? Which brings me to the second most important thing here:
documentation. As you seem to be starting a new project using ZODB,
maybe you could come up with a "Getting started with ZODB in your
own project" or so which would (how I picture it) include a step
by step walkthrough from zero to writing some simple Persistent
classes and using them. That woul make your life easier in the
long run as steps written down correctly tend to be very easy to
reproduce. On the other hand the community would benefit from some
neice peace of documentation.

Is there a ZODB wiki (didn't find one), where we could gather this
stuff? I've come accross a whole bunch of useful code snippets that
a use seldomly but which are very, very useful then. For example
"how do i find/retrieve a object with oid 0xYYYYYYY?", "How do I copy
transactions starting whith tid xxx from one ZODB to another?"

I keep these in my private CMS, where they are obviously only useful
to me. Time for a ZODB wiki?!

Cheers!
Jürgen

> 
> Jim

-- 
>> XLhost.de ® - Webhosting von supersmall bis eXtra Large <<

XLhost.de GmbH
Jürgen Herrmann, Geschäftsführer
Boelckestrasse 21, 93051 Regensburg, Germany

Geschäftsführer: Jürgen Herrmann
Registriert unter: HRB9918
Umsatzsteuer-Identifikationsnummer: DE245931218

Fon:  +49 (0)800 XLHOSTDE [0800 95467833]
Fax:  +49 (0)800 95467830
Web:  http://www.XLhost.de


More information about the ZODB-Dev mailing list