Jim Fulton wrote: > I don't remember if we decided that these would be sent to just you or > to the Web SIG. Since I didn't see any messages go to the Web SIG, I'll > assume we're just supposed to send these to you.
I suppose we could take this to Web-SIG. For those who weren't at the PyCon mini-meeting we had, we talked about creating a cross-framework application server. Basically the thing that deals with PID files, chuser, parts of connection handling, etc. I don't think we've written up anything yet, but hopefully some people who were taking notes can expand. Or... something. Anyway, we talked about using Paste Deploy entry points for configuration. > - I think you were a bit uncomfortable about the use of the > global_config argument to the factory functions. I share this > discomfort a bit. It seems a little odd to expose the configuration > mechanism this much. It isn't a big deal for me. > > What have you used global configuration data for? It's often meant for configuration that applies to many components. For instance, a "debug" value that applies widely (or could also be applied locally). Or information about where to email errors, some logging information, etc. E.g., you might give a base directory for logging in global_conf, and an application could pick that up and probably put it in a subdirectory there (where if you configured it locally, you'd probably give the application the full path of the log file). > - The semantics of paste.server_factory seem to be a little unclear. In > particular, I *assume* that the return value is expected to block when > run. Is this true? If so, then it makes it hard to have more than one > server. I know that you aren't fond of the idea of having multiple > servers, but a lot of other folks seem to want it. :) In any case, the > semantics of the return value need to be documented. paste.server_factory should be expanded, in part for what you are proposing (starting multiple servers). Also, it seems like there should be a better way to shut it down than killing the entire process. For instance, for performance testing. For multiple servers, I'd generally rather have servers support multiple sockets, though this is a little hard in Paste Deploy (you'd might have to use a set of prefixes for configuring each, if you have configuration that is port-specific). But I don't think there's anything wrong with starting multiple servers, if you really are starting truly different servers. This could all be done in the same entry point, with optional methods (instead of just __call__ being specified), or a new entry point (which might be a bit more explicit). > - If multiple servers are supported, then there will need to be a way to > specify which applications are used with which servers. As long as the connection data is there, you can dispatch later (if you want to at all). For instance, most people want http and https to serve the same application. In paste.urlmap configuration I allow things like (in addition to path dispatch): domain foo = foo_app port 443 = https_app domain bar port 8888 = test_app But you can also easily send everything to the same place, or a group of things to the same place. I find this generally more convenient than building dispatch any further down. Arguably the config syntax could support urlmap more natively. E.g., allow sections like [app:/blog]. This could be turned into urlmap construction. Assuming you don't care about the order in which middleware is applied, you could have [filter:/blog] automatically wrap that application. (With multiple middleware on the same location, I suppose you'd have to supply some qualifier.) > Overall, PasteDeploy looks very usable. I'll probably find other issues > when I actually try to use it. One of my next projects wil be to look > at how to use it in Zope. zope.paste is a bit too much of a wedge. zope.paste, as I remembered it, didn't really seem to allow things like instantiating multiple Zope applications. But I can't remember. And that's not always feasible; Zope 2 is unlikely to really support many truly separate instantiated applications, but it could still support the basic configuration. Also note that in practice usually an application presents the entry point directly, and the framework provides functions to make application-specific entry points easy to write. > On a related note, I'll probably want to do process configuration in the > same file that that PasteDeploy uses. This would likely include things > like: > > - interrupt-check-interval > > - Log files > > I guess there is nothing to prevent this. I suspect that I'll also get > a lot of resistence to moving this out of zope.conf. :/ Yes, the container configuration. (Incidentally, what exactly do we call this thing we're proposing to make?) > Have you tried pointing logging.fileConfig at a cnfig file containing > PasteDeplot sections? I assume it would work. I haven't tried it, but I think Ben Bangert has started work on that, using global_conf['__file__'] that way. A more cohesive logging story that included that would be nice. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
