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.
It occurs to me that in these cases, it would probably be more constructive to fork than to reimplement. I suppose that's the kind of environment that people who advocate distributed version control are thinking about. Or alternately repositories with relatively promiscuous commit access -- codespeak is doing this, for instance. Or, it would be convenient to set up subversion so that I could give commit access to limited locations (e.g., /home/username, or /project/experimental, or stuff like that) to self-registered users. I'm a little worried about security in that situation, but I also think that's probably the right methodology.
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.
Well, it's unclear to me if the deployment thing is very interesting, at least with the currently available options. No one (I'd hope) chooses Webware because the AppServer and installation process are so awesome. To make something like WebStack interesting, I think you have to allow for communication between the layers and a more intimately heterogeneous environment. But even then I'm not sure it's that useful.
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.
If CGI didn't have such serious performance problems, I'd totally be using it for everything. So being associated with CGI isn't bad. It represents HTTP, and that's a good start. One thing that occurred to me while writing my WSGIKit presentation is that there's a parrallel when you avoid putting layout and design decisions in code; WSGI is a way of keeping API and aesthetic decisions out of the core infrastructure. That's not to say some more aesthetic conformity wouldn't be nice -- at least some conventions for the uncaring to follow -- but that's an entirely separate issue from WSGI.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
