|
List Info Thread: Re: PasteDeploy comments
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
Re: PasteDeploy comments |
|
List Info Thread: Re: PasteDeploy comments
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
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
colorstudy.com |