[ZODB-Dev] zc.zlibstorage missing from zodb package
Hi friends, I'm trying to work with ZODB. (!) Coming from durus development since a couple of weeks, I am spoiled by simplicity. Actually, I'm annoyed by durus' incapability to accept patches, so I'm considering to put my efforts into ZODB. On the other hand, ZODB tries to become small and non-intrusive, but looking at its imports, this is still not a small package, and I'm annoyed of this package as well. - missing the zc.zlibstorage module is missing, IMHO. besides that, zc.zlibstorage was not maintained since quite a while and imports ZOPE3. - bugs installing ZODB on OS X still gives complaints after Marius' latest patch which did not cover it all. It works, so this is a minor issue. - discussion zc.zlibstorage requites a wrapper to add it to filestorage. I consider this an option, instead, and a simple boolean flag to switch it on and off. The module is way too simple to add all this config extra complication to even think of it. - proposal: let me integrate that with ZODB and add a config option, instead of a wrapper. * this is just the beginning of a series of proposals to ZODB. I would love to use it if it was as small as it claims to be. Or tries to be. There are serious flaws that voiden this nice attempt. At the moment, I'm considering to re-package everything into a really isolated, single package. This is my major reason why I worked on Durus. My reason to go back to ZODB is the better code. But be warned, there are bugs in the BTrees package, which I will report next time. Meant in a friendly, collaborative sense -- Chris -- Christian Tismer :^) mailto:tis...@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/ 14482 Potsdam: PGP key - http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ 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
[ZODB-Dev] BTrees package problems
The BTrees package is an attempt to isolate certain things from ZODB. While I appreciate the general intent, I cannot see the advantage at this point: - BTrees can be imported alone, yes. But it has the extensions prepared with special ZODB slots, which makes this very questionable. - BTrees furthermore claims the BTrees global bame for it, all though it is not a general BTree package, but for ZODB BTrees, only. - BTrees has a serious bug, see the following example: from BTrees import OOBTree as BT t = BT.BTree() for num in range(100): ... k = str(num) ... t[k] = k ... t._firstbucket._next = None len(t) Bus error: 10 (tmp)minimax:doc tismer$ So there is either an omission to make t._next() read-only, or a check of its validity is missing. Actually, I would like to add a callable-check instead, to allow for more flexible derivatives. * this was my second little rant about ZODB. Not finished as it seems. please, see this again as my kraut way of showing interest in improving very good things. cheers -- chris -- Christian Tismer :^) mailto:tis...@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/ 14482 Potsdam: PGP key - http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ 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
[ZODB-Dev] BTrees and ZODB simplicity
Third rant, dear Zope-Friends (and I mean it as friends!). In an attempt to make the ZODB a small, independant package, ZODB has been split into many modules. I appreciate that, while I think it partially has the opposite effect: - splitting BTrees apart is a good idea per se. But the way as it is, it adds more Namespace-pollution than benefits: To make sense of BTrees, you need the ZODB, and only the ZODB! So, why should then BTrees be a top-level module at all? This does not feel natural, but eavesdropping, pretending as something that is untrue. I think: - BTrees should either be a ZODB sub-package in its current state, - or a real stand-alone package with some way of adding persistence as an option. * there is a conclusion following as well. Thanks for audience this far ;-) cheers - chris -- Christian Tismer :^) mailto:tis...@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/ 14482 Potsdam: PGP key - http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ 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
[ZODB-Dev] make ZODB as small and compact as expected
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. I think these things could be re-packed into a common namespace and be made simpler. Even zope.interface could be removed from this intended-to-be user-friendly simple package. 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. cheers -- chris -- Christian Tismer :^) mailto:tis...@stackless.com Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/ 14482 Potsdam: PGP key - http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/ ___ 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
