Am Freitag, den 04.05.2007, 23:54 -0400 schrieb Jim Fulton: > All of the examples I mentioned can be handled very well with a > decorator model.
Yup. My experience with using the proxy approach for is good as well (I worked on the BlobStorage). I'm kind of leaning towards using a proxy approach instead of spelling everything out. I'm not completely convinced that spelling all methods that are copied out is a good thing. If storages have additional methods than it's unclear to me whether it is better that those would not be available or not. For example, IBLOBStorage defines the "storeBlob" method. Storages do not have to provide this method but then they can't store Blobs. I can imagine multiple cases here: 1. Everything is automatically proxied and a method is invoked that your storage doesn't know about (good thing) - the method still works, but you don't get the benefits of your proxy storage 2. Everything is automatically proxied and a method is invoked that your storage doesn't know about (bad thing) - your proxy keeps assumptions about the state of the proxied storage which get out of sync because of the unknown method 3. Everything has to be manually proxied and a method is invoked that your storage doesn't know about (semi-good thing) - your storage fails during tests and you see that you have to support (yet) another method 4. Everything has to be manually proxied and a method is invoked that your storage doesn't know about (bad thing) - you notice during production that your proxy is not "certified" with a certain other storage because it uses a method you didn't know about. your database fails. - your proxy ends up knowing about all other storages (and all other proxy storages) and is very painful to maintain Hmm. In conclusion I have the feeling that deviating from the normal storage interface shouldn't happen too much. Anyway, the DB class and Connection class are the ones dealing with the Storage anyway ... Any additional methods should probably only be for maintenance and keep the existing methods working in an idempotent way. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev