No rants please. Really. Since I started using Webware some years ago that's the first time that I see a serious attempt at putting a security/access framework as "standard" in a python AppServer framework
Got problem with it (uncaught exception, refuse to start, quickstart fails, etc.) => revert to non HEAD revision in SVN trunk, or to "stable" tag. I would really hate seeing Jeff give up. And what next ? Shoot Ronald when Catwalk is failing ? NO (... but really that strange Firefox 1.5 bug triggered by Catwalk nearly killed my nerves and I had a loaded gun ready :-) The lesson for me is: We should put meaningful and extensive data in bug reports: TG revision, RDBMS version, dev.cfg, tracebacks, etc. SQLite 2 vs. 3 is a well-know issue and would have been solved much faster with better reports. On another POV may be the Identity stuff should have been done in a branch... but that would be a hassle to merge due to fast paced revisions in trunk (branching before 1.0 sounds weird...) The more I think about it, the more I get the feeling that CherryPy filters should have been Paste middleware (or alike) : completely independant components, just piped from one into another by configuration data. Don't want Identity ? no prob, just remove it from the pipe. Want FooBarFilter after static and before Identity ? just declare it this way in the pipe. For example an exception middleware would format nice tracebacks (with prettyfied python/HTML source) for *all* TG components. Since CP is "independant" project and CP devs may want to keep filters the way they are, may be TG must keep CP filters as is but somehow hook their output into a Paste architecture to manage his own filters... Using CP filters is handy and built-in, but may be today's TG requirements are above what they where built for... Not sure of anything, just a 2c opinion. Olivier.
signature.asc
Description: OpenPGP digital signature
