On Sun, Jul 21, 2013 at 12:12 AM, Christian Tismer <tis...@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

> 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,

- 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 Fulton
For more information about ZODB, see http://zodb.org/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to