Re: [Zope-dev] 2gb file size
On Fri, Nov 03, 2000 at 01:04:52PM -0800, Andy McKay wrote: > My database has suddenly ballooned to 2 gig's stopping my Zope from running. > Are there any utils to delete the last transaction or so? Try truncating Data.fs to a bit under 2 gigs, then start Zope. It will probably complain about a truncated transaction at a certain offset, write that down and truncate Data.fs again at exactly that offset and you should be ok. -- 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 )
[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 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 )
[Zope-dev] No feedback for SOAP patch ?
Hi, I received zero feedback on the SOAP support patch I sent a few days ago... I no one is interested I guess I should just forget about it and find something else more interesting ? -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] alpha SOAP support
Hi everyone, Here's a very rough cut at adding SOAP support to Zope. It is mostly a shameless adaptation of the already existing XML-RPC support and it probably has alot of problems, but it should provide a starting point. Don't expect too much out of it for now since: 1) it was written by someone (me :) with about two hours of previous SOAP experience and 2) it is 1:34 AM here and I wrote it in the last hour :) Having said that, I was able to call a method inside Zope and retrieve back the result, so I attach a diff against a current Zope CVS checkout. Feedback is more than welcome. -Petru diff -urN --exclude-from=exclude _zope-untouched/lib/python/ZPublisher/HTTPRequest.py soap-zope/lib/python/ZPublisher/HTTPRequest.py --- _zope-untouched/lib/python/ZPublisher/HTTPRequest.pySat Jun 10 02:57:58 2000 +++ soap-zope/lib/python/ZPublisher/HTTPRequest.py Thu Jun 22 01:23:28 2000 @@ -94,6 +94,7 @@ from Converters import get_converter from maybe_lock import allocate_lock xmlrpc=None # Placeholder for module that we'll import if we have to. +soap=None isCGI_NAME = { 'SERVER_SOFTWARE' : 1, @@ -347,13 +348,23 @@ if (fs.headers.has_key('content-type') and fs.headers['content-type'] == 'text/xml' and method == 'POST'): -# Ye haaa, XML-RPC! -global xmlrpc -if xmlrpc is None: import xmlrpc -meth, self.args = xmlrpc.parse_input(fs.value) -response=xmlrpc.response(response) -other['RESPONSE']=self.response=response -other['REQUEST_METHOD']='' # We don't want index_html! + if environ.has_key('HTTP_SOAPACTION'): + # this is a SOAP request + global soap + if soap is None: + import soap + meth, self.args = soap.parse_input(fs.value) + response = soap.response(response) + other['RESPONSE'] = self.response = response + other['REQUEST_METHOD'] = '' + else: + # Ye haaa, XML-RPC! + global xmlrpc + if xmlrpc is None: import xmlrpc + meth, self.args = xmlrpc.parse_input(fs.value) + response=xmlrpc.response(response) + other['RESPONSE']=self.response=response + other['REQUEST_METHOD']='' # We don't want index_html! else: self._file=fs.file else: diff -urN --exclude-from=exclude _zope-untouched/lib/python/ZPublisher/soap.py soap-zope/lib/python/ZPublisher/soap.py --- _zope-untouched/lib/python/ZPublisher/soap.py Thu Jan 1 02:00:00 1970 +++ soap-zope/lib/python/ZPublisher/soap.py Thu Jun 22 01:23:12 2000 @@ -0,0 +1,116 @@ +"""SOAP support module + +Written by Petru Paler + +Based on the XML-RPC Zope support module written by Eric Kidd at UserLand +software, with much help from Jim Fulton at DC. + +This code hooks Zope up to Fredrik Lundh's Python SOAP library. +""" + +import sys +from string import replace +from HTTPResponse import HTTPResponse +import soaplib + +def parse_input(data): +"""Parse input data and return a method path and argument tuple + +The data is a string. +""" +method, params = soaplib.loads(data) +# Translate '.' to '/' in meth to represent object traversal. +method = replace(method, '.', '/') +return method, params + +# See below +# +# def response(anHTTPResponse): +# """Return a valid ZPublisher response object +# +# Use data already gathered by the existing response. +# The new response will replace the existing response. +# """ +# # As a first cut, lets just clone the response and +# # put all of the logic in our refined response class below. +# r=Response() +# r.__dict__.update(anHTTPResponse.__dict__) +# return r + + + + +# Possible implementation helpers: + +class Response: +"""Customized Response that handles SOAP-specific details. + +We override setBody to marhsall Python objects into SOAP. We +also override exception to convert errors to SOAP faults. + +If these methods stop getting called, make sure that ZPublisher is +using the soap.Response object created above and not the original +HTTPResponse object from which it was cloned. + +It's probably possible to improve the 'exception'
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] DirectoryStorage 0.04
Changelog: 0.04: - added missing binary flags to open() calls to make it work on NT. - added flush() calls after file writing - added close() method to the DirectoryStorage class 0.03: - don't die if posix.fsync is not available - base class renamed to DirectoryStorage - added directory (re)creation and locking - added a 'magic' file - last oid file open/close bug - moved serials to an gdbm database 0.02: - converted to using os.path.join 0.01: - initial release -Petru # Copyright (c) 2000 Petru Paler ([EMAIL PROTECTED]) All rights reserved. # To-do list: # Critical: #- Most I/O operations are not atomic. This means that I/O errors (and, for #that matter, any exceptions occured in _finish) leave the storage in an #undefined state # # Not critical: #- Performance tuning -- add caches where apropiate #- make sure locking is ok #- provide directory splitting to enable use on non-reiser filesystems # # ... and probably many others """Directory storage""" __version__ = "0.04" from BaseStorage import BaseStorage from lock_file import lock_file import POSException import os, struct, stat, operator, gdbm try: from posix import fsync except: fsync = None def oid2str(oid): return "%02X"*8 % struct.unpack("!8B", oid) def rmrf(dir): "Recursively delete dir" for f in os.listdir(dir): pathname = os.path.join(dir, f) mode = os.stat(pathname)[stat.ST_MODE] if stat.S_ISDIR(mode): rmrf(pathname) elif stat.S_ISREG(mode): os.unlink(pathname) else: raise 'remove error', 'strange file in dir storage' os.rmdir(dir) MAGIC = 'Directory Storage Format v1.0' class DirectoryStorage(BaseStorage): def __init__(self, dirname, create=0): if not os.path.exists(dirname): create = 1 if os.path.exists(dirname): try: f = open(os.path.join(dirname, 'lock'), 'r+') except: f = open(os.path.join(dirname, 'lock'), 'w+') lock_file(f) try: f.write(str(os.getpid())) f.flush() except: pass self._lock_file = f BaseStorage.__init__(self, dirname) self._oid_dir = os.path.join(dirname, 'oid') self._tindex = [] self._oid = '\0\0\0\0\0\0\0\0' if create: if os.path.exists(dirname): # prune the old dir rmrf(dirname) os.mkdir(dirname) os.mkdir(os.path.join(dirname, 'oid')) f = open(os.path.join(dirname, 'lock'), 'w+') lock_file(f) try: f.write(str(os.getpid())) f.flush() except: pass self._lock_file = f f = open(os.path.join(dirname, 'magic'), 'w+') f.write(MAGIC) f.close() self._sindex = gdbm.open(os.path.join(dirname, 'serial'), 'n') self.lof = open(os.path.join(dirname, 'last_oid'), 'w+b') else: self._sindex = gdbm.open(os.path.join(dirname, 'serial'), 'w') f = open(os.path.join(dirname, 'last_oid'), 'r+b') self._oid = f.read() self.lof = f def __len__(self): return len(os.listdir(self._oid_dir)) def getSize(self): files = os.listdir(self._oid_dir) files = map(lambda x,d=self._oid_dir: os.path.join(d, x), files) sizes = map(lambda x: os.stat(x)[stat.ST_SIZE], files) return reduce(operator.add, sizes) def close(self): self.lof.close() self._sindex.close() self._lock_file.close()
Re: [Zope-dev] Request for comments: Directory storage
> I'd love some sort of benchmarking tool for this (and posibly other > Storages). I guess the best way would a python script that uses urllib. > Something that would algorithmically pump up the DB to > 1GB in size > and retrieve the URL's. Any volunteers or am I doing it in my > copious spare time (tm)? 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 ? > I've got a nice NetApp here to run some tests on. What filesystem does that use ? -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
> I don't have the two on comparable machines :-( > > Do you have a standard benchmark for comparing the relative performance > FileStorage/DirectoryStorage on reiser fs? Not yet. I have been using a script which just creates/retrieves objects from the ODB but I guess something more serious is needed. Will write :) -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
> M. I suspect NTs heavier file security checks will prove to be a > significant disadvantage - benchmarks to follow. If you do benchmarks, you should do them comparing DirectoryStorage/NTFS to DirectoryStorage/reiserfs, because (at least at mass object creation) DirectoryStorage is slower than FileStorage (because of the open() overhead). I plan on optimizing the random access on huge number of objects case. -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] DirectoryStorage 0.03
Note that this version (experimentally) uses a dbm database for storing serials. If you don't have/don't want to use gdbm, replace all occurences of gdbm with dbhash or dumbdbm. I didn't used anydbm because it has some strange problems with my python installation :) (but it will be fixed soon). Changelog: 0.03: - don't die if posix.fsync is not available - base class renamed to DirectoryStorage - added directory (re)creation and locking - added a 'magic' file - last oid file open/close bug - moved serials to an gdbm database 0.02: - converted to using os.path.join 0.01: - initial release -Petru # Copyright (c) 2000 Petru Paler ([EMAIL PROTECTED]) All rights reserved. # To-do list: # Critical: #- Most I/O operations are not atomic. This means that I/O errors (and, for #that matter, any exceptions occured in _finish) leave the storage in an #undefined state # # Not critical: #- Performance tuning -- add caches where apropiate #- make sure locking is ok #- provide directory splitting to enable use on non-reiser filesystems # # ... and probably many others """Directory storage""" __version__ = "0.03" from BaseStorage import BaseStorage from lock_file import lock_file import POSException import os, struct, stat, operator, gdbm try: from posix import fsync except: fsync = None def oid2str(oid): return "%02X"*8 % struct.unpack("!8B", oid) def rmrf(dir): "Recursively delete dir" for f in os.listdir(dir): pathname = os.path.join(dir, f) mode = os.stat(pathname)[stat.ST_MODE] if stat.S_ISDIR(mode): rmrf(pathname) elif stat.S_ISREG(mode): os.unlink(pathname) else: raise 'remove error', 'strange file in dir storage' os.rmdir(dir) MAGIC = 'Directory Storage Format v1.0' class DirectoryStorage(BaseStorage): def __init__(self, dirname, create=0): if not os.path.exists(dirname): create = 1 if os.path.exists(dirname): try: f = open(os.path.join(dirname, 'lock'), 'r+') except: f = open(os.path.join(dirname, 'lock'), 'w+') lock_file(f) try: f.write(str(os.getpid())) f.flush() except: pass self._lock_file = f BaseStorage.__init__(self, dirname) self._oid_dir = os.path.join(dirname, 'oid') self._tindex = [] self._oid = '\0\0\0\0\0\0\0\0' if create: if os.path.exists(dirname): # prune the old dir rmrf(dirname) os.mkdir(dirname) os.mkdir(os.path.join(dirname, 'oid')) f = open(os.path.join(dirname, 'lock'), 'w+') lock_file(f) try: f.write(str(os.getpid())) f.flush() except: pass self._lock_file = f f = open(os.path.join(dirname, 'magic'), 'w+') f.write(MAGIC) f.close() self._sindex = gdbm.open(os.path.join(dirname, 'serial'), 'n') self.lof = open(os.path.join(dirname, 'last_oid'), 'w+') else: self._sindex = gdbm.open(os.path.join(dirname, 'serial'), 'w') f = open(os.path.join(dirname, 'last_oid'), 'r+') self._oid = f.read() self.lof = f def __len__(self): return len(os.listdir(self._oid_dir)) def getSize(self): files = os.listdir(self._oid_dir) files = map(lambda x,d=self._oid_dir: os.path.join(d, x), files) sizes = map(lambda x: os.stat(x)[stat.ST_SIZE], files) return reduce(operator.add, sizes) de
Re: [Zope-dev] Request for comments: Directory storage
> > Hello all, > > > > You probably saw my yesterday post with the first alpha of > >ReiserStorage. > > Woohoo! > > Id like to try this on NT with NTFS too (which has similar performance > characteristics with big directories and small files). Do you think > this is worth a try, or does your ReiserStorage use other > Unix-specific tricks? The version I sent to the list assumes a '/' directory separator. I'm releasing a fixed version (a snapshot of my working code) in a couple of seconds. I do think it's worth a try, but I doubt NTFS is as good as ReiserFS :) -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
> From my naive understanding, would this help with the problem ZODB has > with regard to folders with many objects? Would a person who is using > DirectoryStorage not necessarily be required to partition their objects > into an artificially derived hierarchical directory structure? No, these are unrelated. DirectoryStorage is a storage for ZODB and doesn't really care about what the application (Zope in this case) stores in it. > In other words can it be a possible solution to > http://www.zope.org/Wikis/zope-dev/ReallyBigFolders ? > > Ooo, if so any idea on ETA? I don't know. Michel Pelletier has released an alpha BTreeFolder, but I didn't had time to look at it.. -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
> >Glad you find it interesting :) > > Very. I think the line between FileSYstem and Database gets more blurred > every day. That's what Hans Reiser says all the time :) > Thanks for the heads up. I have to patch my kernel up to 2.2.11 first, > then I'll be recompiling, then creating. It may take me a bit. But I sure > as heck want to try it. Thanks again. 2.2.11 ? You should really use the latest kernel (2.2.15 at this time, 2.2.16 due to be out soon). -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
> This is the embodiment of my MutliFileStorage thingy on Jim's ZODB Wiki. I Oops, didn't saw the ZODB Wiki until now :) > droped it (Never picked it up) when Mountable Storage was announced. I'll > create a ReierFS partition some time this week and try it out. Excellent! Glad you find it interesting :) One thing I should mention is that you should use the rupasov hash option on the partition. teahash will also work, but rupasov hash is designed for consecutive file names and DirectoryStorage specifically exploits that feature. -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