[ZODB-Dev] make ZODB as small and compact as expected
Jim Fulton
jim at zope.com
Mon Jul 22 13:27:06 CEST 2013
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
More information about the ZODB-Dev
mailing list