Ian, > 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.
Many can't/won't spend for a "a dedicated server (virtualized, not an actual box)". We are looking at sites that are one step up from free hosting without a proper domain name. I want to write web apps in TurboGears that will be used to make cheap non dynamic hosting appear a little more dynamic without them needing to host their own applications. Example. Church websites often have a list of worship services. These are often maintained by hand and so on far too many sites they are out of date. The "proper" solution is for a database backed site that automatically filters the list of services by date. That is overkill for most of these. I want to provide a simple web app that runs as a single turbogears instance where Churches can register and then enter their services in a list. Each Church to automatically get their own database file and the url to indicate which church this is for. The Website gets this data from the web app in a variety of ways according to preference (AJAX from website/webapp uploading the data on a weekly basis via ftp/...). So for this type of webapp which is going to be free I need to be able to host as easily as possible on my textdrive account. I don't want a shared database and I don't want to have to create new configurations/instances each time a church registers. As web apps become smaller units that get assembled into larger clusters I feel that this model will be widely needed. > 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. It is hosted/managed apps that I am looking at. > You mean determine the connection uri programmatically? I guess you > could do that, but that seems a bit odd. That sounds like me ;-) > 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. That sounds like what I am wanting. > That's what the hub is intended to do. Good. >>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. Ok. >>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. Yes. Dave
