[Zope-dev] Product release: ExtFile/ExtImage 0.91
Version 0.91 of the ExtFile/ExtImage Software Product has just been released. The ExtFile and ExtImage Products store large files in an external file-repository and are able to display icons for different MIME-Types. The ExtImage Product additionally creates preview-thumbnails from images and displays them. ExtFile and ExtImage basically work like the Zope File and Image products but the (binary) file is not stored inside the ZODB, but in an external file-repository. Only meta data (like title and description) are stored in the ZODB. This prevents the Database swelling up quickly, when many large files are uploaded and thus increasing database performance. Version 0.91 fixes an important security issue, that allowed read access to any file in the local filesystem (readeable for the UID of the zope process). The Product is avaliable at http://www.zope.org/Members/MacGregor/ExtFile/ MacGregor! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] _delObject Method
Hello! Can anybody tell me, what the 'dp=1' attribute in the _delObject methods of the ObjectManager (OFS/ObjectManager.py) and ZClassMethodsSheet (ZClasses/Method.py) Class are for? I haven't found any method call, where dp is set and the methods themselves don't use it aswell. I would like to use it as a switch for (not) calling the manage_beforeDelete method, when the _delObject method is called by CopySupport.manage_renameObject and CopySupport.manage_pasteObject. In these cases, manage_beforeDelete would not be called. To me that seems to be correct, because during a cut-paste and a rename operation the Objects are not really deleted, they are just temporarily taken out of the object-tree and then inserted again. Are there any problems with that? Or is 'dp' used for another purpose in an older or a newer version of Zope (I use Zope 2.1.6)? -OFS/ObjectManager.py-line 277- def _delObject(self, id, dp=1): object=self._getOb(id) if dp: object.manage_beforeDelete(object, self) self._objects=tuple(filter(lambda i,n=id: i['id']!=n, self._objects)) self._delOb(id) --- -OFS/CopySupport.py-line 225 and 259--- ob.aq_parent._delObject(id, 0) --- Thanx, Gregor! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Distributed ZODB-Transactions
Zopistas! I want to write an Product that mirrors every ZODB-Transaction to a Backup-Server. The idea was to trap every transaction (i.e. creation, change, deletion of zope-objects) and transfer a copy of the object to another server (via XML-RPC?!?) after the transaction got commited. I've been debugging through various zope-classes (esp. transaction.py, connection.py) but couldn't understand the way, zope manages the transactions. The creation and deletion process always seems to trigger a transaction for the parent object. Has anybody an idea? Thanx, Gregor! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Distributed ZODB-Transactions
I want to write an Product that mirrors every ZODB-Transaction to a Backup-Server. The idea was to trap every transaction (i.e. creation, change, deletion of zope-objects) and transfer a copy of the object to another server (via XML-RPC?!?) after the transaction got commited. I've been debugging through various zope-classes (esp. transaction.py, connection.py) but couldn't understand the way, zope manages the transactions. The creation and deletion process always seems to trigger a transaction for the parent object. Has anybody an idea? Data.fs is essentially a log file that is appended with binary data. The only time the data is changed rather than appended is when you pack the database. Therefore, it may be easier to write a script that catches the data that is appended and appends it to the backup file. When the script detects the file has shortened (after a packing operation), it should copy the whole file over. The simple fact that data is appended rather than changed makes Data.fs quite reliable. It can withstand most kinds of failure. And the Zope undo mechanism is very effective. So I would suggest that the backup you intend to perform does not need to be an integral part of Zope. Rather, it is appropriate that it be a background process run periodically. Shane OK, I admit, I didn't tell you the whole truth. ;-) The Backup-Server should not only backup one, but various Zope-installations (sort of 'backup-central'). My idea was to create a folder for each backuped server. This folder holds the complete object-tree of a backup-client. Each time a change in the database of the client occurs, the client informs the server about it (tells the server which object has been changed, created or deleted). Then the server requests that object from the client. The client pickles the object, sends it to the server and the server unpickles it again and puts it in the right place in the client folder. My problem is the first step: how does the client recognize, which object has to be updated? In the case of a creation and deletion of an object, the transaction-class handles the parent object and not the object itself. Thanx, Gregor! ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )