9.22.2003

To Zope or Not to Zope

After poking around Zope at lunch, I noticed there's a lot of stuff that Zope does that's specific to Zope: DTML and ZPT templates and the built in OO database and scripts and all sorts of stuff.

This got me worried. I started thinking it'd be a "bad thing" if we got trapped into using Zope. I figured we ought to look into some of the other Python app servers and see if they were a little less proprietary.

I posted as such to the developer list.

Tom responds and asks what's wrong with that, and I answer that you need to be free to choose your server and not be tied down to a particular make and model. A classic response, but Tom's not convinced.

Then it occurs to me that Tom programs a lot of Microsoft, so "vendor-lock" isn't something he thinks about very often. And yet, he seems to get by just fine. Really, the more I thought about it, I realized my response was almost pure reflex, and I was making something out of nothing.

But we looked at it anyway. We batted it around, thinking about the risks, and we ended up deciding "what the hell". But we decided figured "what the hell" for good reasons.

1: Python is a scripting language and doesn't have a framework or template pages like JSP, ASP or PHP. So, if any server wants to make some, they're going to be proprietary anyway.

2: Where else would we go? To another fully-functional, easy-to-use, free Python server? Why, there are so many to choose from!

3: XP dictates you do the simplest possible thing. Right now, that means take Zope and go with it. I had concerns about what happens if we outgrow our local boxen and want to take this to a hosted solution. Uh, yeah, we'll worry about that should it ever happen. In the meantime, why penalize ourselves. Besides, who hosts Python apps right now anyway?

So, in short, we thought about it, and we're going deep in with Zope, as the risk is minimal, and the rewards are substantial.

It's pretty neato, really.

posted by risser at 21:04

Nobody has anything to say.