Tom Schwaller wrote:
> 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
* 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
* 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 / ianb@... / http://blog.ianbicking.org