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

[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.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton