<<back to planning

Non-Deliverance tasks

• Virtual hosting, i.e., domains like myorg.org (they have to point their domain to us, or like wiki.myorg.org) or myorg.openplans.org (automatic)
• Virtual email hosting for lists?  Maybe (probably) not.
• Using Javascript <script>'s to include openplans content on a non-openplans site.
  

Future tasks for Deliverance

• currently when you try to proxy from www.openplans.org/projects/deliverance, it produces a weird error instead of saying that you cannot proxy from a directory/page; currently, you can only proxy from http://www.site.com (without a trailing slash); perhaps this should be extended to allow for proxying subdirectories of a site; the rules parameter must be a full uri... this should be stated
  
• when the proxy can't load the remote site, it hangs indefinitely instead of timing out
  
• Figure out what to do when there's badly invalid HTML (lxml does some handling, if tidy etc are not an option, maybe just require that it's decent)
  
• consider popups, which probably shouldn't be styled
  
• Consider complex cases like folding together navigation from both theme and content; decide whether this is feasible, and offer techniques.
• add xinclude support to theme?
• more grueling tests
• xpath errors are not caught in the xslt renderer
• on certain platforms (gentoo for example), the buildout does not properly link lxml against the built versions of libxslt and libxml2. This is a distutils problem at its root (it does pass the proper linking flags to gcc because it is confused about the compiler type on any system where the gcc binary name does not begin with "gcc". We should probably include a script to set LD_LIBRARY_PATH rather than just a README about it.
  

Community:

• announce on mailing list
  
• Help drum up support, bring people to the actual Deliverance list to discuss these things

Rule patterns:

• Some head rules are complex.  Should we abstract these some way?

Consider caching:

• Caching based on HTTP header information (currently just a time window)
  
• Heavy caching can be confusing to users (changes don't actually cause anything to change).
• I will spec this out -- Ian
  

Deployment:

• continue testing with and fleshing out topp.zwsgi
• Do more performance benchmarks, to see what the overhead is (using, say, ab or FunkLoad)
• Consider reviving the Apache/mod_python portion of this, for benchmarking
• Also the in-Zope/Five technique
• Also use paste.proxy to pipe the request to Zope (living out of process) from the WSGI server.  We can even use this to wrap the existing and live openplans.org site.
  
• Actually deploy in front of Zope/openplans (dev or locally hosted server)
• turn the example in readme.txt into a doctest