Ian, >> 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).
Ok I understand your terminology use. However, for small (or very small) applications (think http://www.tadalist.com/) and for very budget constrained clients (think small British Churches) this is overkill. I am not convinced that this is the way to scale either. For applications where there are a lot of clients relative to the total volume of requests it is more effective to have a single application instance/installation that can dynamically handle multiple clients. Obviously this is not true for custom apps where each client pays for a different implementation. >> 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. H'mm, I like the even simpler solution of a single configuration and a dynamically per request built connection url. >> 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. I would like to see a Hub that makes all this transparent and configurable. So that at development time I can fireup the builtin http server and work with multiple clients, each with their own database in the same instance. At deployment time I want to be able to choose, one instance per client, multiple instances per client (load balancing accross processors), one instance with multiple clients (Fred and all his family each with a blog on a cheap hosted service). Ideally my app should not change, just the hub configuration. Dave
