[Web-SIG] Re: Just lost another one to Rails

[Paul Boddie]

On Tuesday 19 April 2005 17:53, Martijn Faassen wrote:
>
> This sounds good. I think it would be good if Python web frameworks
> turned more into users of a cloud of focused, smaller, libraries and
> mini-frameworks.

That would be great!

> I've sighed a few times the last months when I ran into more and more
> Python-based schema and form frameworks. I developed Formulator for Zope
> 2 pretty early on, and was involved in 2002 in setting up Zope 3's
> schema framework, so I've contributed to the problem. In the Zope world
> there's also Archetypes, and I heard Archetypes is now working on a new
> generation which redesigns everything.. And I ran into Schevo and I saw
> formencode, which both have a history too, and then finally what made me
> sigh was running into a weblog post by Philip Eby on Spike. It all looks
> all very cool, but how many more do we need here?

For what it's worth, I've also developed some schema and form frameworks. ;-) 
I think the reason for the re-invention, also in the Web frameworks arena, is 
that people look at the design decisions and think, "That's horrible! I don't 
want to have to write that when doing that - why can't I just do this?" Not 
that certain aspects of, for example, Schevo don't look highly intriguing.

> I believe that what we, framework developers, need is a bit more
> humility ("We're open, you just all plug into our great solution!" is
> not humble), and more active outreach to include pieces of other
> frameworks. While we also need to do a bit of work of opening up the
> neat bits of our frameworks to reuse by others, but that rather easily
> turns into the non-humble "Use mine!", so I think what we really need to
> do more of is the "Let's look for something to reuse!" variety of
> outreach than the "look, I made mine real great!" outreach (we'll do the
> latter automatically anyway :). I think Ian Bicking has been saying
> similar things.

The whole point of WebStack was to re-use as much as possible of the different 
frameworks. When I started it, I wanted to avoid dealing with the network 
plumbing and the tedious aspects of HTTP, although I'd have more confidence 
now to rewrite some of the higher-level things of the frameworks that I'm 
plugging into. Things like cgi.FieldStorage I wanted to remain opaque, but 
I'd feel more ready now to rewrite it if I felt that it would be a worthwhile 
activity.

What I've sort of deduced from the discussions over the past few years is that 
people may want interoperability, but they want the magic cloud of 
interoperability to expose no API. WebStack gives you the possibility of 
deployment on eight frameworks but exposes an API which isn't cool enough, or 
something like that. But even WSGI exposes an API of sorts, and the only 
clear benefit it has over its chief inspiration, CGI, is that one isn't 
constantly reaching for the raw environment variables and I/O streams - it's 
either to its advantage that a well written CGI application could surely have 
been implemented on top of a similar layer years ago (since that would make 
such an application fairly open to porting now), or a statement that the road 
of consensus ends pretty quickly once you get out of town.

> Zope has historically suffered from a sometimes massive lack of humility
> in this respect, though I think my community is not the only one which
> has been too interested in reinventing wheels. There have been various
> attempts in the past to open things up, and I've chipping away at Zope
> (3) a bit in my own way:
>
> http://faassen.n--tree.net/blog/view/weblog/2005/04/15/0

In my opinion, ClearSilver was one of the more under-rated template 
technologies.

> More excitingly, recently there's been an absolutely great iniative by
> others to integrate Zope 3 with Twisted using WSGI, and all kinds of
> coolness may develop from that eventually.

I honestly hope that the guts of Zope 3 don't perpetuate the nastiness found 
in Zope 2's HTTP objects.

Paul