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

[Ian Bicking]

Paul Boddie wrote:
>>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  /  ianb at colorstudy.com  /  http://blog.ianbicking.org