On Tue, 2005-02-01 at 16:18 -0600, Ian Bicking wrote:
Winston Wolff wrote:
Is anybody here going to be going to Pycon? Care to do a sprint on Webware?
Would be nice, but I'm not in DC this year.
Maybe a "Python Web framework Unification" sprint would be interesting or something like best "Python clone of Ruby on Rails" sprint (Subway, WSGIKit/Webware based one, ...) with the goal of extracting the best ideas and using them in all frameworks afterwards... This is maybe not the original idea of sprints, but nevertheless useful as a kind of "cross framework sprint"
I really wished we had something like a very lightweight container like the spring framework in Java, but written in Python (OK Zope X3 can be considered as something analogous to Spring, but maybe this is not what everybody is looking for in the Python world) and all Python frameworks would be just special plugin assemblies in that container, so you do not have to choose between frameworks but just between your preferred plugins. just dreaming.. ;-)
I brought up the idea of a reference/common/standard set of WSGI middleware on the Web-SIG list, but didn't get much reaction. It could be pressed harder. I'll copy my message from there:
What do people think about collaborating on a kind of "standard" library of WSGI middleware? (Not standard like distributed-with-Python, just well publicized.) This is what I've tried to put together a little with WSGIKit, though not all parts of it would apply. And other people are, I think, starting to develop the same things, perhaps with some overlap. Maybe we can pool our efforts together.
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!)
I have to admit, I get frustrated these days when I work on the Webware core :(
What exactly is frustrating you? Is there a remedy for that frustration?
Well, it's not the way I want it to be. It's hard to test. It has lots of unused or redundant interfaces. It's not well documented or well documentable. It combines concepts that don't need to be combined. It's hooks for extension are sometimes misdesigned or fragile. Some things aren't as convenient as I'd like them to be, yet fixing that would mean even more redundant interfaces. There's a lot of good parts too -- I'm basically pretty happy with the servlet model. I like SitePage. Component actually works better than I'd expect, even those it's patched on top of something that wasn't designed for it (WebKit.Page). But while I feel I can refine some pieces of my own applications, it doesn't create a framework for others to work with a more refined layout.
With my frustration with documentation, I hate trying to explain something when there's not a good reason for it. I feel a need to apologize for cruft. And there's just too many little details to explain, without an overriding direction or purpose to serve as a framework for those ideas.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
