[Repoze-checkins] r610 - www/trunk/blog.repoze.org/entries

[Tres Seaver]

Author: Tres Seaver <tseaver at palladion.com>
Date: Fri Dec  7 21:55:57 2007
New Revision: 610

Log:
Incorporate changes from Chris.

Modified:
   www/trunk/blog.repoze.org/entries/faster_application_restart.txt

Modified: www/trunk/blog.repoze.org/entries/faster_application_restart.txt
==============================================================================
--- www/trunk/blog.repoze.org/entries/faster_application_restart.txt	(original)
+++ www/trunk/blog.repoze.org/entries/faster_application_restart.txt	Fri Dec  7 21:55:57 2007
@@ -1,8 +1,8 @@
-Faster Application Restart
+Highway Jam  Faster Application Restart
 #label general
 <p>
    While driving back from North Carolina, Chris McDonough and I spent
-   the time talking about ways to make the Repoze developer more
+   the time talking about ways to make WSGI developers more
    productive.
 </p>
 
@@ -17,6 +17,8 @@
 
 <p>In no particular order, here are the ideas we came up with:</p>
 
+<h4> Python-based </h4>
+
 <ul>
  <li>Move the current profiling support out of Zope-the-application
      and make it middleware, so we can measure the various bits
@@ -24,27 +26,54 @@
      but only for one request at a time.</li>
 
  <li>
+     When doing a "fast" restart, signal first an event which allows
+     listeners to dump any global state to a cache on the filesystem;
+     then, on restarting, arrange to signal another event which allows
+     listeners to reload that state, short-circuiting the whole application
+     initialization phase.
+ </li>
+
+ <li>
+     In development mode, maybe we can trigger the fast restart whenever
+     any of
+     <code> [getattr(x, '__file__', None) for x in sys.modules.values()]</code>
+     changes.  Can we somehow arrange for the triggering request to be
+     retried after the restart?  Does it matter?
+ </li>
+
+ <li>
+     We should definitely tie into the support which
+     <code>paste --reloadr</code>
+     had for auto-restart.
+ </li>
+
+</ul>
+
+<h4> Zope-related Changes </h4>
+
+<ul>
+
+ <li>
+     Maybe find a way to add all parsed ZCML files, to the "watched files"
+     list too, so that changing ZCML will automagically restart the
+     application.
+ </li>
+
+ <li>
      Finish making ZCML parsing side-effect free, so that we can cache
      the action list (to a ".pyc"-like file) across application runs
-     (a "pickle file").</li>
+     (a "pickle file").
+ </li>
 
  <li>
-     That would imply preventing the "eager validation / resolution"
-     of dotted names, currently done at parse-time.  Instead, the parser
+     Removing ZCML-parse-time side-effects implies removing the
+     "eager validation / resolution" of dotted names.  Instead, the parser
      would create "deferreds" representing the target objects, which would
      then be resolved / replaced at the point of use.  We would presumably
      be able to serialize the deferreds in the "pickle file" mentioned above.
  </li>
 
  <li>
-     When doing a "fast" restart, signal first an event which allows
-     listeners to dump any global state to a cache on the filesystem;
-     then, on restarting, arrange to signal another event which allows
-     listeners to reload that state, short-circuiting the whole application
-     initialization phase.
- </li>
-
- <li>
      One particularly interesting bit of global state is the set of
      pickles cached by each ZODB connection.  Repopulating those caches
      after a restart is one reason that Plone, for instance, takes so
@@ -69,13 +98,4 @@
      bypass them on restart (e.g., PlacelessTranslationService).
  </li>
 
- <li>
-     In development mode, maybe we can trigger the fast restart whenever
-     any of
-     <code> [getattr(x, '__file__', None) for x in sys.modules.values()]</code>
-     changes.  Maybe find a way to include all parsed ZCML files, too.
-     Can we somehow arrange for the triggering request to be retried after
-     the restart?  Does it matter?
- </li>
-
 </ul>