Dave Warnock wrote:
Ian,
If each application had its own configuration file and independent
existance then this shouldn't be any problem -- URLs won't be conflated
with applications, and it will only be in unusual situations where an
application will have more than one database connection. As you enter
the application you set the connection, and restore it (probably just
delete it) on the way out of the app. Anyway, this doesn't help that
much, because you can't do this now. But really everything will become
much simpler when it is possible!
We may be understanding "application" differently. In my understanding I
may have a single application running for multiple clients. Therefore
the single TurboGears application may need multiple databases - one per
client.
The terminology is a little fuzzy. There's applications, which are
bundles of code, and application instances/installations, which are
applications with configuration (and maybe some setup routines applied).
For simple hosting I would want a single wsgi server running an
application that uses the url to partition by client with a separate
database for each (so that I don't have to worry about including the
client in every database key).
Sure, this would mean two application instances, with two
configurations, but using one codebase. If configuration is applied on
a per-request basis, this isn't a problem. I've done this with some of
my apps successfully.
I would assume that adding a separate application instance for each
client when their usage will be small would be a big overhead (memory
and management).
I use a single process for multiple applications, and generally a single
process per "client", but that depends on how heavy your clients are.
Foo Corp might get its own process. My cousin who wants a blog might not.
It might not be too bad to have a single process per app instance, if
the processes were made mostly on demand, and culled over time.
Especially if there was a single manager, so you could actually go down
to zero processes for an idle application.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
