It sounds like it might be useful to have an entry point group for objects that describe a simple set of configuration options for an application. Then, you could have the WSGI Server product have a class for application instances, that would have a dropdown list to select the entry point and display a form to do the configuration. You could basically have a Zope item that wraps the WSGI application with a check for some "manage" URLs that would go to the item, and the rest of the URLs would belong to the wrapped entry point.
More precisely, the entry points would be factories with some metadata on 'em, and you could just throw away and recreate the application objects when the configuration was changed. It sounds like something worth growing a spec for, so that you can create automatically-generated GUIs for app instance configuration and deployment.
On the other hand, maybe applications should just provide their own configuration interfaces, in which case the meta-spec could be a lot simpler... more like "pick the entry point and create an instance". In which case we would more want to have an ability for an app to store some configuration data, perhaps via a service in the environ.
So, you'd have something like this: define a factory entry point. The factory gets called with some opaque configuration data, or None if it's a new application. When the app runs, if it wants to update its configuration, it calls something in its environ, to ensure that the next time it's created, the factory will be passed the saved configuration.
Voila, instant "container" support, as long as the application can provide some kind of configuration UI of its own. It's not really useful for creating middleware stacks directly, but the container's UI might be able to do that. Anyway. It's an interesting thought which I unfortunately have no time to try implementing right now. :)
Incidentally, Ben Bangert was just talking about the exact same thing on IRC today.On the other hand, maybe applications should just provide their own configuration interfaces, in which case the meta-spec could be a lot simpler... more like "pick the entry point and create an instance".
That seems more reasonable to me. Of course, bootstrapping is also a bit complex; but in this case I assume the interface would be a web interface. Any other interface doesn't seem quite reasonable. The other idea I had was a command to write out a basic configuration file -- potentially drawing from some "global" options, though defining what those might be would be a rather organic process. Anyway, given the basic configuration file, you just edit it, and then probably do a final installation stage.
The difficult part is that the environment the application runs in is often not a proper environment for the application to be set up in. Permission issues being the most immediate issue -- the app might have to run as root to create the right directories or whatnot. But I simply have no web environment that I typically run as root. And though I could install to a remote host that way, it's a little suspect.
That said, I certainly can appreciate the idea of a nice web UI for installation. It could lead fairly quickly to a installation process like:
- Download ez_web.py
- Run python ez_web.py (which is basically ez_setup.py plus installation of a few base packages that will be used in the next step)
- Run... something. ez_web.py would install something that was a combination of easy_install and then a post-install process that runs the application installer. easy_web perhaps.
- Open the URL it tells you to open, and configure
That doesn't really handle the issue of a long-running process. There's no easy way to figure that out, really. You could configure that too when you set it up, but it's so bound to the environment you are running in that it's hard. And it will fail in all sorts of ways that will keep you from the configuration screen itself.
But, Wise Web Hosts would have easy_web already installed and configured for the environment.# Ian Bicking