[Zope-dev] RFC: page contracts
Hi eveyone. While playing around with the development version of ACS (ArsDigita Community System), I noticed a very nice feature they introduced, namely page contracts. In ACS, this means that every tcl page starts with a call to ad_page_contract. In the parameters passed, you specify: - general page documentation (what it does) - author(s) - creation date (not needed for Zope since we have bobobase_modification_time) - CVS ID (not quite applicable for Zope (yet?)) - the expected input variables (from forms) along with their default values (where applicable) and types (having a couple of types like "integer" and "string" predefined and an easy-to-use plugin system to add custom types) - an optional validation block in which you can check the input data ranges and validity (you can also make validation rules depend on each other so if one fails, the rules which depend on it aren't tried) - an optional custom error messages section (to use when one of the required input variables is not there or does not match the format, or when a validation block fails). If you don't provide this some reasonable defaults are provided. IMHO, such a feature would be very useful for Zope too. I find myself quite often doing input validation and error handling in DTML, which is (to say the least) painful. I would be interested to give a try at implementing this, but before starting I wanted to hear community's opinion on: - whether this would be useful - how this should be aproached (the two possibilities I have in mind until now are either a separate manage tab for the page contract, and there a HTML-based interface for building it, either a dtml-contract tag which surrounds the page contract (written in python probably) and placed at the top of DTML documents/methods). -- Petru Paler, mailto:[EMAIL PROTECTED] http://www.ppetru.net - ICQ: 41817235 ___ 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] No feedback for SOAP patch ?
On Fri, Jun 23, 2000 at 10:34:50PM -0400, Evan Simpson wrote: I've barely had a free second with functioning brain capacity this past week, but I'm interested. More so now that Secret Labs has announced their SOAP client library at http://www.pythonware.com/products/soap If you That made me to do it :^) (and it is partly guilty for why it isnt working as good as it should...). haven't already popped your patch into the Collector, please do! I just did now -Petru ___ 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] Request for comments: Directory storage
It would be great if you could do it, but beware that you will be benchmarking a lot of overhead if you only plan to measure storage performance. Why not use ZODB directly ? If I talk HTTP, it measures things fully - Python's interpreter lock will mean a storage system written in python will benchmark better without having to compete with ZServer, and vice versa for storage systems with non-pythonic bits. Yes, you are right. What filesystem does that use ? No idea :-) Something log based that is very fast and handles huge directories happily. It also appears that another member of this list has an EMC Symmetrix box to test on, which I believe is the next (and highest) level up from a Netapp. Mmmm... I heard that Network Appliance hired a couple of the SGI engineers that designed XFS ? I've attached a prerelease alpha of zouch.py for giggles. Not even a command line yet, so you will need to edit some code at the bottom. The current settings generate about 360 directories and about 36000 files, and proceeds to make about 18 reads. This bloated by test ZODB to just over 200MB and took about 2.6 hours attacking my development Zope server from another host on my LAN. Cool :) Thanks for writing this, it will be very useful for benchmarking. -Petru ___ 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] Request for comments: Directory storage
Hello all, You probably saw my yesterday post with the first alpha of ReiserStorage. One of the questions that people tend to ask about it is wheter they can use it without reiserfs. There are two problems with not using reiserfs: 1. ReiserStorage (now renamed to DirectoryStorage) stores each object in a separate file and *all* the files in a single directory. This was done in order to let the filesystem what it was meant to do: store and retrieve files quickly. While reiserfs is *extremely* good at this (it uses a btree to store directory entries), most other filesystems do linear searches when finding a file so performance is very bad when you have many files in a single directory. This problem can be solved by splitting files into multiple directories when not using reiserfs. This would add a little overhead but it is tolerable. 2. Waste of space. Typical block-allocation filesystems like ext2 and FAT will waste alot of space in the usage pattern of DirectoryStorage. ReiserFS packs small files together in the btree, so it solves the problem, but I have no ideea how this could be fixed easyly on the other fs's. Comments ? Suggestions ? PS: a new DirectoryStorage release will be done today, with bugfixes and new features. -Petru ___ 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] ReiserStorage 0.01 alpha
Hello all, Attached you can find the code for a preliminary ZODB storage manager which is designed to take adventage of the reiserfs filesystem (http://devlinux.com/namesys). While it is usable on other filesystems too, the performance will decrease as the number of objects in your database increases. Comments: 1. This is as alpha as it can be. While it is usable to do some testing on a spare Zope, you must be insane to even try to use this on a production system. 2. A generic DirectoryStorage is comming soon, with the diference being splitting files by directory (and, of course, being slower than the reiserfs version). 3. As you can see in the source, I/O errors in critical points can corrupt the storage. 4. It currently does not support versioning and undo. I'm working first on getting it stable and fast, and then add these features. Feedback is not only welcome, but wanted :) -Petru ## # # Zope Public License (ZPL) Version 1.0 # - # # Copyright (c) Digital Creations. All rights reserved. # Copyright (c) 2000 Petru Paler ([EMAIL PROTECTED]) All rights reserved. # # This license has been certified as Open Source(tm). # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions are # met: # # 1. Redistributions in source code must retain the above copyright #notice, this list of conditions, and the following disclaimer. # # 2. Redistributions in binary form must reproduce the above copyright #notice, this list of conditions, and the following disclaimer in #the documentation and/or other materials provided with the #distribution. # # 3. Digital Creations requests that attribution be given to Zope #in any manner possible. Zope includes a "Powered by Zope" #button that is installed by default. While it is not a license #violation to remove this button, it is requested that the #attribution remain. A significant investment has been put #into Zope, and this effort will continue if the Zope community #continues to grow. This is one way to assure that growth. # # 4. All advertising materials and documentation mentioning #features derived from or use of this software must display #the following acknowledgement: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #In the event that the product being advertised includes an #intact Zope distribution (with copyright and license included) #then this clause is waived. # # 5. Names associated with Zope or Digital Creations must not be used to #endorse or promote products derived from this software without #prior written permission from Digital Creations. # # 6. Modified redistributions of any form whatsoever must retain #the following acknowledgment: # # "This product includes software developed by Digital Creations # for use in the Z Object Publishing Environment # (http://www.zope.org/)." # #Intact (re-)distributions of any official Zope release do not #require an external acknowledgement. # # 7. Modifications are encouraged but must be packaged separately as #patches to official Zope releases. Distributions that do not #clearly separate the patches from the original work must be clearly #labeled as unofficial distributions. Modifications which do not #carry the name Zope may be packaged in any form, as long as they #conform to all of the clauses above. # # # Disclaimer # # THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY # EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR # PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL DIGITAL CREATIONS OR ITS # CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, # SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT # LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF # USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND # ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, # OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT # OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # # This software consists of contributions made by Digital Creations and # many individuals on behalf of Digital Creations. Specific # attributions are listed in the accompanying credits file. # ## # To-do list: # Critical: #- Most I/O operations are not atom
