[Framework-Team] repoze.zope2

2008-12-19 Thread Chris McDonough
Hi folks,

I was encouraged to write down the main differences between the stock Zope2
publisher and the publisher that is inside repoze.zope2 (which is in use by the
current Plone trunk).

- Conflict error retry management is moved out into WSGI middleware
  (repoze.retry).

- Trace (-M) logging is moved out into WSGI middleware (see repoze.debug).

- Access (apache-style) logging is moved out into WSGI middleware (see Paste's
  translogger).

- Transaction management is moved out into WSGI middleware (see repoze.tm).

- Top-level exception handling is moved out into WSGI middleware (cgitb
  or evalerror)

- Logging exceptions to the console is now performed by middleware
  (repoze.errorlog).

- An alternate spelling for virtual hosting is supported (no
  VirtualHostMonster needed).  See http://plope.com/Members/chrism/vhm_victory.
  Note that traditional virtual hosting still works, however, as well.

- You can return any iterable to the publisher (such as a file), and it will
  be treated as the response.

Some fallout from these differences:

Some advanced stuff is configurable via the paste.ini file, such as the
publisher output encoding (encoding), the Zope root object name (appname),
and whether or not we try to do a redirect for a browser default
(browser_default_redirects).  These are set to the least surprising options by
default.

standard_error_message will not work because the publisher no longer acts as
the top-level error handler.  A pretty exception handler will need to be
plugged in as WSGI middleware.

The error_log object will not work.  Use zope.errorlog instead (visit
/__error_log__ in the browser).

No testing has been done with IStreamIterator objects.  These may or may not
work.  If they don't work, it's trivial to make them work.

The most recent version of repoze.zope2 is 1.0 available from
http://dist.repoze.org/zope2/latest/.  The subversion repository is
http://svn.repoze.org/repoze.zope2/trunk/ .

I'll be happy to help with any porting problems / questions.

- C

___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


Re: [Framework-Team] repoze.zope2

2008-12-19 Thread Martin Aspeli
We should probably send this to the plone-developers list rather than
the framework team list... Sorry, not on my computer now so can't do
this efficiently, but the discussion belongs there.

And thanks! :)

Martin

2008/12/19 Chris McDonough chr...@plope.com:
 Hi folks,

 I was encouraged to write down the main differences between the stock Zope2
 publisher and the publisher that is inside repoze.zope2 (which is in use by 
 the
 current Plone trunk).

 - Conflict error retry management is moved out into WSGI middleware
  (repoze.retry).

 - Trace (-M) logging is moved out into WSGI middleware (see repoze.debug).

 - Access (apache-style) logging is moved out into WSGI middleware (see Paste's
  translogger).

 - Transaction management is moved out into WSGI middleware (see repoze.tm).

 - Top-level exception handling is moved out into WSGI middleware (cgitb
  or evalerror)

 - Logging exceptions to the console is now performed by middleware
  (repoze.errorlog).

 - An alternate spelling for virtual hosting is supported (no
  VirtualHostMonster needed).  See http://plope.com/Members/chrism/vhm_victory.
  Note that traditional virtual hosting still works, however, as well.

 - You can return any iterable to the publisher (such as a file), and it will
  be treated as the response.

 Some fallout from these differences:

 Some advanced stuff is configurable via the paste.ini file, such as the
 publisher output encoding (encoding), the Zope root object name (appname),
 and whether or not we try to do a redirect for a browser default
 (browser_default_redirects).  These are set to the least surprising options 
 by
 default.

 standard_error_message will not work because the publisher no longer acts as
 the top-level error handler.  A pretty exception handler will need to be
 plugged in as WSGI middleware.

 The error_log object will not work.  Use zope.errorlog instead (visit
 /__error_log__ in the browser).

 No testing has been done with IStreamIterator objects.  These may or may not
 work.  If they don't work, it's trivial to make them work.

 The most recent version of repoze.zope2 is 1.0 available from
 http://dist.repoze.org/zope2/latest/.  The subversion repository is
 http://svn.repoze.org/repoze.zope2/trunk/ .

 I'll be happy to help with any porting problems / questions.

 - C

 ___
 Framework-Team mailing list
 Framework-Team@lists.plone.org
 http://lists.plone.org/mailman/listinfo/framework-team


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


Re: [Framework-Team] repoze.zope2

2008-12-19 Thread Chris McDonough
Well, I sent this here mostly because the decision to use repoze.zope2 in the
trunk is defacto currently (made by Hanno).  There's no PLIP for WSGI support in
Plone 4.  So this is mostly a heads up to the framework team about the scope of
the differences, so they can judge the amount of work required to make a 
release.

Martin Aspeli wrote:
 We should probably send this to the plone-developers list rather than
 the framework team list... Sorry, not on my computer now so can't do
 this efficiently, but the discussion belongs there.
 
 And thanks! :)
 
 Martin
 
 2008/12/19 Chris McDonough chr...@plope.com:
 Hi folks,

 I was encouraged to write down the main differences between the stock Zope2
 publisher and the publisher that is inside repoze.zope2 (which is in use by 
 the
 current Plone trunk).

 - Conflict error retry management is moved out into WSGI middleware
  (repoze.retry).

 - Trace (-M) logging is moved out into WSGI middleware (see repoze.debug).

 - Access (apache-style) logging is moved out into WSGI middleware (see 
 Paste's
  translogger).

 - Transaction management is moved out into WSGI middleware (see repoze.tm).

 - Top-level exception handling is moved out into WSGI middleware (cgitb
  or evalerror)

 - Logging exceptions to the console is now performed by middleware
  (repoze.errorlog).

 - An alternate spelling for virtual hosting is supported (no
  VirtualHostMonster needed).  See 
 http://plope.com/Members/chrism/vhm_victory.
  Note that traditional virtual hosting still works, however, as well.

 - You can return any iterable to the publisher (such as a file), and it will
  be treated as the response.

 Some fallout from these differences:

 Some advanced stuff is configurable via the paste.ini file, such as the
 publisher output encoding (encoding), the Zope root object name 
 (appname),
 and whether or not we try to do a redirect for a browser default
 (browser_default_redirects).  These are set to the least surprising 
 options by
 default.

 standard_error_message will not work because the publisher no longer acts 
 as
 the top-level error handler.  A pretty exception handler will need to be
 plugged in as WSGI middleware.

 The error_log object will not work.  Use zope.errorlog instead (visit
 /__error_log__ in the browser).

 No testing has been done with IStreamIterator objects.  These may or may 
 not
 work.  If they don't work, it's trivial to make them work.

 The most recent version of repoze.zope2 is 1.0 available from
 http://dist.repoze.org/zope2/latest/.  The subversion repository is
 http://svn.repoze.org/repoze.zope2/trunk/ .

 I'll be happy to help with any porting problems / questions.

 - C

 ___
 Framework-Team mailing list
 Framework-Team@lists.plone.org
 http://lists.plone.org/mailman/listinfo/framework-team

 


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


Re: [Framework-Team] repoze.zope2

2008-12-19 Thread Chris McDonough
Raphael Ritz wrote:
 Chris McDonough wrote:
 Hi folks,
   
 
 Hi Chris,
 
 thanks a lot for this detailed and helpful summary.
 
 At least I do appreciate you sending this here ;-)
 
 And yes, I noticed Hanno moved Plone trunk over to this
 so I consider this very relevant and timely.
 
 There is only one further question I would have and that
 regards the level of maturity of the individual components
 from your POV. From what I know you are using most of
 this (or all?) in production yourself, do you?

Yes, we use all of it in production.  repoze.zope2 (and the middleware upon
which it depends) has been in development since last November, so it's fairly
mature.  This site, for example, is currently a repoze.zope2 site:

http://environmentalhealthnews.org/

- C


___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team


[Framework-Team] Re: Hanno Schlichting Plone 4 release manager

2008-12-19 Thread Jon Stahl

Erik Rose wrote:

The Plone 4.0 framework team is pleased to announce our recommendation 
of Hanno Schlichting as the 4.x release manager. Hanno is a Plone 
Foundation member and a prolific committer across diverse parts of the 
Plone codebase (http://www.ohloh.net/accounts/hannosch). We're 
confident that his perspective and dedication will drive the next 
generation of Plone to excellence.


So congratulations to Hanno Schlichting on his nomination; we look 
forward to working with him on the next major release of Plone!


Thanks, Eric  FWT! 

A quick update from the PF board: Our next official meeting won't be 
until January 4th, but we've already taken a straw vote via email and 
there was *considerable* enthusiasm for Hanno (to put it mildly!).


His formal confirmation as Release Manager will be the first item on our 
agenda when we reconvene after the holidays. 


best,
jon


Jon Stahl
President, Plone Foundation



___
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team