[Zope-Checkins] CVS: Zope/doc - CHANGES.txt:1.625.2.125

[Chris McDonough]

Update of /cvs-repository/Zope/doc
In directory cvs.zope.org:/tmp/cvs-serv2971/doc

Modified Files:
      Tag: Zope-2_7-branch
	CHANGES.txt 
Log Message:
Merge chrism-publishfile-branch.  See http://dev.zope.org/Wikis/DevSite/Proposals/FasterStaticContentServing for more information.


=== Zope/doc/CHANGES.txt 1.625.2.124 => 1.625.2.125 ===
--- Zope/doc/CHANGES.txt:1.625.2.124	Tue Mar 23 15:27:22 2004
+++ Zope/doc/CHANGES.txt	Sun Mar 28 06:11:46 2004
@@ -6,7 +6,70 @@
 
   Next release
 
+    Features Added
+
+     - Zope application code can now return a "stream iterator" object
+       to ZPublisher.  If a stream iterator is returned from
+       application code, it will be unwound by Zope's networking code
+       and its data will be rendered as the body of the response to a
+       client.  An example:
+
+          def method_returning_a_stream_iterator(self):
+	      import os, stat
+              from ZPublisher.Iterators import filestream_iterator
+	      path = '/var/zope/Z2.log'
+              size = os.stat(path)[stat.ST_SIZE]
+	      self.REQUEST.RESPONSE.setHeader('Content-Length', size)
+              return filestream_iterator('/var/zope/Z2.log', 'r')
+
+       'filestream_iterator' is a class which implements the
+       "IStreamIterator" interface, which just signifies a "normal"
+       Python iterator that is guaranteed to iterate over a stream of
+       bytes.  This interface is defined within the
+       ZPublisher.Iterators module.  Any instance of a class which
+       implements this interface may be returned to ZPublisher.
+
+       Before a stream iterator is returned from Zope code the
+       'Content-Length' header of the response *must* be set.
+
+       The major use for this feature is to allow application code to
+       serve static files from the filesystem without first needing to
+       read all file data into memory or explicitly chunking data from
+       static files out via 'RESPONSE.write' (both of which are slower
+       than just letting medusa itself handle the output via a native
+       producer).
+
+       http://dev.zope.org/Wikis/DevSite/Proposals/FasterStaticContentServing
+       has more information.
+
+     - OFS.Image's index_html method now calls its own ZCacheable_set
+       method with the single argument None.  Existing cache managers
+       such as HTTPAcceleratedCacheManager and RAMCacheManager will do
+       nothing with this value, but other cache managers are free to
+       inspect the caller and cache its data.
+
+     - OFS.Image's index_html method now attempts to retrieve data
+       from a cache manager via its own ZCacheable_get method.
+       Previously, this method did call in to ZCacheable_get, but did
+       nothing with the data that it retrieved (under the assumption
+       that there are no cache manager implementations which could
+       handle large file data).  Existing cache managers will return a
+       null value from ZCacheable_get, but future cache managers will
+       be free to return a stream iterator, which can be returned
+       directly to the publisher.  For a sample implementation of such
+       a cache manager, see cvs.zope.org:/Products/FileCacheManager.
+
+     - OFS.Image's manage_FTPget now attempts to get data from a cache
+       manager before sending back data out of the database.
+
     Bugs Fixed
+
+     - FTP download speed was very slow because the buffer size used
+       for the feeding of data into asyncore was very small.  Increasing
+       it to a "normal" amount sped up FTP downloads by ~ 100X.
+
+     - OFS.Image's insanely long index_html method was factored out
+       into several parts.
     
      - ZCatalog result/brain methods getPath() and getObject() now properly 
        propagate database conflict errors which should eliminate spurious