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 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 _______________________________________________ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
