The criteria I'd consider:
* Should be something we could do Right, i.e., can become "complete". E.g., a proxying WSGI application could be complete. A commenting system can't.
* Shouldn't involve much UI. Mostly because it can't be very complete.
* Shouldn't be tied to anything very specific. E.g., if there's a templating middleware (um, don't ask me exactly what that would look like) it shouldn't be bound to any particular templating language. Those kind of bindings should probably be part of the upstream libraries.
* Provide robust architecture more than a pleasant API. E.g., WSGIKit implements Webware (more or less), but when you use that you see very little of the middleware that WSGIKit uses. And that middleware looks kind of ugly, what with the environment and string keys and the sometimes funny semantics.
* Be really well documented and stable (at least once we come to consensus on an interface), so that people could reliably and easily used these middleware components in their frameworks.
* Testable and tested.
Some candidates I imagine:
* Sessions middleware
* Logging middleware/library (based on the standard library of course)
* Error reporting middleware/library
* Test frameworks (?)
* A file application (handling If-Modified-Since, etc)
* A proxy application
* Libraries for parsing query strings and all that. Most of what is in Phillip's wsgiref.
* Authentication (this would be on the ambitious end)
* URL parsers (several, but maybe we could distill this down to a few primary models for parsing)
* And maybe a few of the more boring servers, like the CGI server, which will otherwise be homeless (or widely repeated).
I'd expect everyone involved to have ulterior motives, i.e., they'd all have their own separate pet projects and whatnot, and wouldn't be looking to this library (alone) to solve all their needs. And that would be good, another part of what would keep this from being Yet Another Framework. Together this should be attractive to people who like to delete code ;) (Code deleted is code debugged!)
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
