Ian Bicking: the old part of his blog

Re: More Small Apps

Oh, a small note in addition: I think it's too easy to put that any TurboGears application becomes simply available to Zope users once all the WSGI glue is in place. Even forgetting the need for integration that still occurs and is more complicated than a simple module import, TurboGears has a relational database backend requirement. I worry about such requirements when I think about deployment of my applications, especially when such a deployment happens at customer sites. easy_install gives me hope that I'll have to worry less in the future, but that doesn't mean I can stop worrying altogether.

Comment on More Small Apps
by Martijn Faassen

Comments:

There is a database setup procedure, in this case mostly specific to SQLObject. There's no specific protocol for how you set up an application or its database, so this remains an issue. I'd like for there to be a parrallel setup procedure, so that after configuring the application you could explicitly set it up, including having it tell you what it is going to do (without doing it).

There are other kinds of integration that are harder, of course, like permission controls, or other user data. But these are points for future consideration; even if it initially means duplication in some places, having access to a larger set of software is still useful.

# Ian Bicking

Strictly speaking, Turbogears doesn't actually have a RDBMS requirement. 99% of applications that are written for TG will use one and it's geared towards that kind of development, but you don't have to have one installed. It would actually be possible to use a ZODB backend with turbogears. If a ZODB backend were written for SQLObject (if that's even possible), it could make integration even easier.

There are already Plone products that require an RDBMS though (eg, KNotes) so it wouldn't be a totally new thing.

But yeah, in general, any kind of heterogenous deployment is going to be more of a hassle than something totally self-contained.

# anders

But yeah, in general, any kind of heterogenous deployment is going to be more of a hassle than something totally self-contained.

But only for the initial deployment. At least in my experience, heterogeneous deployment is a lot easier to maintain, because there's fewer dependencies all around. Well, good heterogeneous deployment of course; an ad hoc variety of deployments is no fun.

This might not be true for a very small user, for whom everything seems ad hoc because they do so few installations and never become familiar with any particular process. But that same user probably is less attached to a framework and to integration than a larger user might be, so some of the downsides to heterogeneous environments aren't as much of an issue.

# Ian Bicking