[Web-SIG] PasteDeploy comments

[Ian Bicking]

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 | ianb at colorstudy.com | http://blog.ianbicking.org