Dave Warnock wrote: > 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 don't really understand how it's overkill. A configuration file is overkill? If so(?), the files map to simple function calls, so you could do it that way. For something like small British Churches, I think the concern is more maintainability than anything. They can easily afford a dedicated server (virtualized, not an actual box), with more than enough power for them. They just can't maintain the result. So I'm not sure exactly what the issue is. One aspect of the fact that configuration files map to function calls is that you can create an application that contains other applications (delegating to the other app, and passing through specific configuration). This might make the result more maintainable. > 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. It depends what your setup is. If you are doing hosted/managed applications, this is quite reasonable with the Paste model. If you are expecting people to deploy there own apps, I think it's unreasonable that they should share a Python process. Just way to messy; sharing a Python process implies a *lot* of trust, more than is reasonable for different clients. And not just don't-do-bad trust, but don't-mess-stuff-up trust. > 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. You mean determine the connection uri programmatically? I guess you could do that, but that seems a bit odd. But ConnectionHub does make it easy(ish) to set a connection within a certain scope. E.g., if you are hosting two apps in the same process, when the request started it would determine which app (probably via URL) and enter that application via some function call, and that call would have a "database" parameter. The application (with the help of the framework that app uses) would set the hub.processConnection on the way in, and delete it when the request was finished. >>>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. That's what the hub is intended to do. > 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). I think the language is getting fuzzy there. The first two are, as I think about it, both "one instance". One is a load balanced instance, but still one instance. One logical application installation. The last is multiple instances, all served from a single process. > Ideally my app should not change, just the hub configuration. The framework should handle the hub configuration. There's also two concepts of "application", I guess -- I'm talking about it from the outside, where its an implementation detail that it uses TurboGears. Maybe you are thinking of it from the inside, where application code is the code you write that uses TurboGears. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
