Actually all the processes live in one process, so there's only one server. When a request comes in, it is dispatched to the appropriate application. Well, it works with forking servers too, but the applications still share a pool of processes in that case.
It would be cool to be able to spawn applications in subprocesses, and I could actually see a lot of utility in that, but it's not something that is possible now.
Paste Deploy does import modules for both application and server, and then plug them together. Well... the actual importing is typically done through Eggs (and entry points), but that's the basic idea.
Ok - so it's like the QLime configuration module I wrote earlier (no longer available). Would Paste also instantiate any class I want and attach it anywhere? Both Quixote and CherryPy publish a tree of objects. In Quixote (don't know about CherryPy) this 'tree' is build by Python code. Do you think it would be useful if I could (via configuration) specify how to build the published tree? For example, instantiate class someusermanager.User and attach it at root.user.
It doesn't use a tree of objects, so it's not exactly like that. egg:Paste#urlmap matches URL prefixes and redirects them to applications (which are in turn configured in another section or file). It doesn't use any kind of object publisher, so it doesn't construct any set of objects. Internally the application is free to parse the rest of the URL using an object publisher. I find the composition of distinct applications through assignment to be... well, it makes the applications no longer distinct. Monkeypatching objects to make the resolver happy is... well, not so hot either.
Typically an application will provide a simple callable, that in turn will instantiate the class. This can be provided by your framework, or embedded in the application itself. Since some frameworks don't have a root class, this concept isn't built in. (e.g., some frameworks simply have a root directory)# Ian Bicking