CherryPy's wsgiserver chunks the write if the application returns no
Content-Length header at all (and certain other conditions don't intrude). See
https://bitbucket.org/cherrypy/cherrypy/src/tip/cherrypy/wsgiserver/wsgiserver2.py?#wsgiserver2.py-928
Robert Brewer
fuman...@
long history of stability from its CherryPy ancestry. It
should run equally well on UNIX and Windows, and Pythons 2.4 to 3.2.
Robert Brewer
fuman...@aminus.org
[1] https://bitbucket.org/cherrypy/cheroot
___
Web-SIG mailing list
Web-SIG@pytho
hen
gzip, then cache". By introducing egress filters as described in PEP 444 (which
mentions gzip as a candidate for an egress filter), you're then stuck in a
tug-of-war as to whether to build a new caching component as middleware, as an
egress filter, or (most likely, in order to compe
ould be rewritten again to
something like:
for f in ingress_filters(controller):
if f.on(environ['path_info']):
f(environ)
It was for these reasons that CherryPy 3 ditched its version 2 "filters" and
replaced them with "hooks and tools" in versio
Benoit Chesneau wrote:
> On Wed, Sep 22, 2010 at 5:34 PM, Robert Brewer
> wrote:
> > However, the caveat requires a caveat: servers must still be able to
> protect themselves from malicious clients. In practice, that means
> allowing servers to close the connection without
lications* to do this; the WSGI "origin" server can do so
quite easily.
However, the caveat requires a caveat: servers must still be able to protect
themselves from malicious clients. In practice, that means allowing servers to
close the connection without reading the en
y appreciate it if your web3 spec made some definitive decision on
whether applications and middleware are responsible for correctly
differentiating HEAD from GET, or whether servers should transform HEAD
to GET before invoking the first application callable. I'd personally
prefer the former.
ings instead of just
waiting for the status and headers to be available? Do you then run off and do
other things with that server thread?
I've run a few businesses now on WSGI without doing what you describe, so I
don't see why blocking makes an application 'trivial'.
Ro
under a Web3 stack.
This middleware will require, when under Python 3, an equivalence
to be drawn between Python 3 str types and the bytes values
represented by the HTTP request and all the attendant encoding-
guessing (or configuration) it implies.&qu
the Python 2 branch (just as Python itself has been doing,
if you notice). If you do that, we can write a WSGI for Python 3 now
that doesn't suffer from any of the complexities of 2to3.
Robert Brewer
fuman...@aminus.org
___
Web-SIG mailing list
Web-S
. People can then objectify those ADTs to their
representational taste.
Robert Brewer
fuman...@aminus.org
[1] http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
[2]
http://www.cherrypy.org/wiki/ZenOfCherryPy#a8.Subclassedbuiltinsarebette
rthancustomtypes.
___
approach in CP 3.x is to subclass cherrypy.lib.sessions.FileSession (or
one of the others), and add your own calls where you want them, then
just stuff your new class into the sessions module via
"cherrypy.lib.sessions.MyFileSession = MyFileSession" (and the config
system will automatic
P.J. Eby [mailto:p...@telecommunity.com]
> At 07:40 PM 9/21/2009 -0700, Robert Brewer wrote:
> > Yes; you have to transcode to the "correct" encoding. Once.
> > Then every other WSGI application interface "below" that one
> > doesn't have to
Henry Precheur wrote:
> On Mon, Sep 21, 2009 at 03:26:35PM -0700, Robert Brewer wrote:
> > It looks simpler until you have a site that is not primarily utf-8.
> > In that case, you multiply your (1 line * number of middlewares in
the
> > WSGI
> > stack * each request).
I've never proposed that WSGI make choices for people. I'm simply saying that a
configurable server, with a sane, perfectly-reversible default, is the simplest
thing that could possibly work.
Robert Brewer
fuman...@aminus.org
> -Original Message-
> From: Mark Nott
', 'surrogateescape')
>
> With utf8-then-latin1:
>
> environ['some_key'].encode(environ['some_key.encoding'])
>
>
> The 'surrogateescape' way is clearly simpler.
It looks simpler until you have a site that is no
P.J. Eby wrote:
> At 11:23 AM 9/21/2009 -0700, Robert Brewer wrote:
> >I still don't see why the environ should have multiple versions of
> >anything. It's not as if the HTTP request gives us multiple
> >Request-URI's. There's a single processing step that
René Dudfield wrote:
> On Mon, Sep 21, 2009 at 6:05 PM, Robert Brewer
> wrote:
> > Armin Ronacher wrote:
> >> WSGI will demand UTF-8 URLs and only
> >> provide iso-XXX support for backwards compatibility.
> >
> > WSGI cannot demand that;
est. I discussed this at
length in
http://mail.python.org/pipermail/web-sig/2009-August/003948.html
Robert Brewer
fuman...@aminus.org
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.pyth
e web bits of the
> stdlib and asked, "Should this work on strings, bytes, or both, and
> if both, how should that API be expressed?"
Perhaps not, but I wrote unquote_bytes at PyCon 2009, after discussing
urllib in the python-dev room and being told no bytes-compatible version
> determine what encoding to use for both of the path part and the query
> string.
No, it won't fail. WSGI servers do not perform %-decoding of the
QUERY_STRING. In the example given, a WSGI 1.1 server will set the
Python 3 environ values:
{'SCRIPT_NAME&
or Python 3 that's
> broken here. How much of the stdlib are we talking about needing to
> reimplement, aside from cgi.FieldStorage?
urllib.unquote, for one. We had to make a version which accepts bytes
(and outputs bytes). But it's only 8 lines of code.
Robert Brewer
fuman...@aminus.o
4 a bit, but IMO should not outweigh my goals 1, 2, and 3.
> The second question is, do we want to try and come up with something
> for Python 3.X, ie., (2) above, while still preserving the current
> start_response() callback, or do we instead want to jump direct to
> WSGI (Python
Armin Ronacher wrote:
> Thanks to Graham Dumpleton and Robert Brewer there is some serious
> progress on WSGI currently. I proposed a roadmap with some PEP
changes
> now that need some input.
>
> Summary:
>
> WSGI 1.0 stays the same as PEP 0333 currently is
>
comes down to me not have the real world
> experience in writing web applications to know best.
>
> What I would like to hear is PJE (who tends towards #3) and Robert
> Brewer (who tends towards #4). Can you guys give counter explanations
> as to why there arguments for bytes isn't vali
n this regard.
> ...
> For the three reasons above, I don't think we can assume that the
> application will always receive equivalent URI's encoded in a
> single, foreseen encoding.
Did I say 3 reasons? I meant 4: Accept-Charset.
Robert Brewer
fuman...@aminus.org
___
ler, or stuck in
some parameter list/dict. In many cases, the charset used to decode these
values either: is unimportant; follows complex rules from one resource to
another; or is merely reencoded, since the application really does care about
bytes and not characters. Falling back to ISO-8859
environ
entry so apps can transcode it if the server got it wrong.
Re:bytes. We really do not want the server to set any of the above environ
entries (except REQUEST_URI) to bytes. I'm surprised those of you who have
substantial numbers of WSGI middleware aren't fighting this; it would mean
.chunked_write = True
self.outheaders.append(("Transfer-Encoding", "chunked"))
else:
# Closing the conn is the only way to determine len.
self.close_connection = True
Robert Brewer
fuman...@aminus.org
___
bda x: (x.Name in ['Dave', 'Jerry', 'Sue']) or (x.Size ==
30))
>>> c = logic.Expression(lambda g, h: g.Name == h.Name)
>>> c
logic.Expression(lambda g, h: g.Name == h.Name)
>>> a + c
logic.Expression(lambda x, h: (x.Name in ['Dave
Graham Dumpleton wrote:
> 2009/5/12 Robert Brewer :
> > There's a major change in functionality in the cgi module between
> Python
> > 2 and Python 3 which I've just run across: the behavior of
> > FieldStorage.read_multi, specifically when an HTTP app accepts a
s designed to accept incremental writes,
but I haven't yet found a way to do any kind of incremental reads
from it in order to shunt the fp.read out to a tempfile again.
I'm secretly hoping Barry has a one-liner fix for this. ;)
Robert Brewer
fuman...@aminus.org
_
P.J. Eby wrote:
> At 08:07 AM 5/8/2009 -0700, Robert Brewer wrote:
>> I decided that that single type should be byte strings because I want
>> WSGI middleware and applications to be able to choose what encoding
>> their output is. Passing unicode to the server would requir
t of the response.
Perhaps WSGI 2's mythical "return (status, headers, body-iterable,
encoding)". Middleware could then decode/transcode as desired. I can't
think of a downside to that, other than some lost cycles spent
de/encoding, but perhaps there are some I don't ye
e to use unicode strings everywhere, yet still allow
some to specify exact bytes as necessary. In shorter: don't worry about
that part, we've got it covered. ;)
Robert Brewer
fuman...@aminus.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
ng any unforeseen impediments.
>
> Are you moving to use of empty string as end of input sentinel for
> wsgi.input for case where code does actually read more than
> CONTENT_LENGTH?
Sure; I think that's reasonable. It's supposed to be 'file-like'.
Robert Brewer
fu
TRING.
> This should be equivalent with what wsgiref does in Python 3.X and
> basically keeps the status quo.
>
> If anyone has any last things to say on all of this, please speak up
> now.
>
That sounds fine to me, Graham, and is what I'll be implementing in my
python3 bran
d apps far
outnumber origin servers).
Robert Brewer
fuman...@aminus.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
s, at least until http-bis is
widespread. I'd be OK with making the app do it as needed (since only it
might know whether extension headers are token/quoted-string/TEXT).
Robert Brewer
fuman...@aminus.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
t; isn't so specific about encodings.
I don't think that's true. Referer must be absoluteURI or relativeURI,
neither of which have defined encodings. RFC 2047 only applies to
headers of type TEXT, of which there are surprisingly few.
Robert Brewer
fuman...@aminus.org
encoding which the app can override. Looking at the
above, ISO-8859-1 is the best encoding I know of for all three header
cases. ASCII can be used as a valid subset without transcoding; headers
which are ISO-8859-1 are decoded perfectly; URI/IRI headers can be
transcoded by the app if needed, but mangl
sallows them). I'd be much happier referring to 3875,
and even happier diverging from strict compliance to what was always a
shaky spec.
Robert Brewer
fuman...@aminus.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
Graham Dumpleton wrote:
> 2009/4/2 Robert Brewer :
> > Alan Kennedy wrote:
> >> Hi Graham,
> >>
> >> I think yours is a good solution to the problem.
> >>
> >> [Graham]
> >> > In other words, leave all the existing CGI variables
sting Python web stuff
> that tries to.
http://www.cherrypy.org/browser/trunk/cherrypy/lib/http.py#L196
Currently, CP apps call that. We can move that to the server if desired.
Robert Brewer
fuman...@aminus.org
___
Web-SIG mailing list
Web-SIG
the server *is* configurable, deployers should be able to
choose Latin-1 if they need to recover the original bytes, without
having to support a separate set of encoded-byte entries.
Side note: wrapping the wsgi.input fp in a DecodingWrapper before
Graham Dumpleton wrote:
> 2009/4/2 Guido van Rossum :
> > On Wed, Apr 1, 2009 at 12:15 PM, Ian Bicking
> wrote:
> >> On Wed, Apr 1, 2009 at 11:34 AM, Guido van Rossum
> wrote:
> >>> On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer
> wrote:
> >
Guido van Rossum wrote:
> Sent: Wednesday, April 01, 2009 9:34 AM
> To: Robert Brewer
> Cc: Web SIG
> Subject: Re: [Web-SIG] Python 3.0 and WSGI 1.0.
>
> On Wed, Apr 1, 2009 at 5:18 AM, Robert Brewer
> wrote:
> > Good timing. We had been thinking to make ever
the app would be best-qualified to decode those three.
I hope to discuss that further this morning at the sprints. Turns out
the cgi module in Python 3 only does text, not bytes. I considered
submitting a patch to make it handle bytes for fp/environ but that
became difficult quickly and m
eduling of WSGI improvements (version roadmap)
* Lifecycle methods (start/stop/etc event API driven by the container)
Robert Brewer
fuman...@aminus.org
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
h
I wrote:
> We had a good second meeting and answered more issues. My
understanding
> is that there is another BoF scheduled for tomorrow (Sunday). Check
the
> Open Space board for details.
My mistake. I'll put up an Open Space reservation for 5pm today ASAP.
Robert Brewer
fuman
ents
* Asynchronous WSGI support. Mostly non-existent. Fix it? Fork it?
Drop it?
* Lifecycle methods (start/stop/etc event API driven by the container)
* Remove app_iter.close?
Robert Brewer
fuman...@aminus.org
___
Web-SIG mailing list
Web-SI
w out the middle, it's got no way to do so
> without
> dropping back to its own caching scheme that the framework can't
> coordinate with other schemes; but it seems to cover the majority of
> cases that I can think of.
Those seem like strategies for individual middleware com
rd Request/Response objects. There was one call for, and many
against, this.
* Lots of little changes: the server's supported HTTP version,
file_wrapper edge cases, etc.
* Python 3, and the scheduling of WSGI improvements
* Asynchronous WSGI support. Mostly non-existent. Fix it? Fork it? Dro
ions for this, and flup has forking options (you'd
> use flup
> > behind Apache or another server).
>
> Yes, i also could use an async server. But i would like to identify
> (and
> reproduce) exactly the problem.
> I also use a lot of cached data in my app. Anyway i
Graham Dumpleton wrote:
> 2008/11/28 Robert Brewer <[EMAIL PROTECTED]>:
> > CherryPy's wsgiserver will read any remaining request body (which
the
> > application hasn't read) before sending response headers.
>
> A WSGI application could technically want to
reliably receive the response message. However, this
requirement is not be construed as preventing a server from
defending itself against denial-of-service attacks, or from
badly broken client implementations.
CherryPy's wsgiserver will read any remaining request body (which the
gt;
> > You can't just modify the current WSGI 1.0 spec.
> >
> > I'm for 2), with the other clarifications about WSGI we have
> discussed
> > in the past.
>
> I'm for 1. What other clarifications were you thinking of?
PLEASE don't ask, don't tell.
+1
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:web-sig-
> [EMAIL PROTECTED] On Behalf Of Ian Bicking
> Sent: Sunday, November 16, 2008 10:06 AM
> To: Graham Dumpleton
> Cc: Web SIG
> Subject: Re: [Web-SIG] Revising environ['wsgi.input'].readline in the
> WSGI specification
>
>
in the request body with
POST. If you have further questions, you should ask at comp.lang.python:
http://mail.python.org/mailman/listinfo/python-list
Robert Brewer
[EMAIL PROTECTED]
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.or
A tcpdump would be more helpful at this point, but I'm not sure the ML
is the right place for that.
Robert Brewer
[EMAIL PROTECTED]
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:web-sig-
> [EMAIL PROTECTED] On Behalf Of Tibor Arpas
> Sent: Tuesday, July 22,
this.
One possible answer is that wsgiref doesn't disable the Nagle algorithm
[1].
Try changing WSGIServer.server_bind to read:
def server_bind(self):
"""Override server_bind to store the server name."""
import socket
self.socke
set_local_implementation(imp):
> global local
> local = imp
>
>
> If a wsgi server wants to implement request-local storage by using the
> environ, it would call set_local_implementation with an imp function
> that closes over the environ for eac
Matt Goodall wrote:
> Yes, it can be tedious but I believe explicit arg passing
> is necessary to make code readable, testable and reusable.
> ...
> I've made the mistake of relying on magic contexts in the
> past. I'm still trying to fix things.
Can you elaborat
ope 3, there are proxy objects sitting at cherrypy.request and
cherrypy.response which shuttle getattr and setattr to
cherrypy.serving.request/response. That allows app code to just "import
cherrypy" and have access everywhere.
Now, cherrypy.serving _is_ a
ed as an abs_path consisting of two path_segments ['', 'path'],
not a net_loc, since the Request_URI must be one of ("*" | absoluteURI |
abs_path | authority).
Robert Brewer
[EMAIL PROTECTED]
See
http://www.cherrypy.org/browser/branches/815-urljoin/cherrypy/wsgiserver
h function a
"resource". I'd still rather have real resources that align with
application state, but it makes for a good transition strategy from
existing RPC mechanisms.
Robert Brewer
[EMAIL PROTECTED]
___
Web-SIG mailing list
Web-SIG@python.
John Millikin wrote:
> On Sat, Apr 5, 2008 at 7:01 PM, Robert Brewer <[EMAIL PROTECTED]> wrote:
> > Re: Representation of Fractional Numbers, there are two solutions. If you
> > return decimals, people using JS on the other end are going to call
> > float(d).
> >
wing the caller of parse() to choose would be even
better.
Robert Brewer
[EMAIL PROTECTED]
___
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
84=ABngstr=C3=B6m?=' to
u'\\u212bngstr\\xf6m'. See [2] for where that happens. PEP 333 only
talks about 2047 encoding, not decoding, and also says "All
encoding/decoding must be handled by the application", so we made the CP
WSGI server pass 2047-encoded request headers through
nt to encode decimal as a
> string for example, because the other end is probably going to parse
> JSON numbers as doubles.
Thanks for allowing that; the last 3 JSON projects I've been involved
with have had Python on both ends, and always passed Decimal, never
floating-point.
Robert
Bob Ippolito wrote:
> On Thu, Mar 20, 2008 at 5:50 PM, Robert Brewer <[EMAIL PROTECTED]>
> wrote:
> > Deron Meranda wrote:
> > > And even then, we're not just talking about a JSON parser.
> > > We're all doing more than that; we're mapping Python
numerals to become Python decimals, you
shouldn't be forced to lose information just because the json decoder
was only designed to hand you a float. Arbitrary converter plugins would
be icing on the cake. A built in decimal converter would be heaven. :)
Robert Brewer
[EMAIL PROTECTED]
__
Just an update and reminder. We're in room 1021 of the Marriott Renaissance
through Sunday night. Looks like we have a good-sized crew already and it's
only Thursday. :) Call anytime!
Robert Brewer
[EMAIL PROTECTED]
From: [EMAIL PROTECTED] on behalf
ike to anyone who works on web libraries, servers, or frameworks (or
their friends; don't let domain boundaries stop you ;).
Robert Brewer
[EMAIL PROTECTED]
619 374 1117
[1]
http://www.marriott.com/hotels/travel/chibr-renaissance-chicago-ohare-su
ites-hotel/
_
to go from Cookie
> into cookielib at some point and to deprecate cookielib2 in 3.x).
>
> cookielib -> http.cookies
> Cookie -> http.cookies2 (same thinking as above).
>
> cookielib -> cookies.client
> Cookie -> cookies.parsing
I'd propose:
Cooki
just moved into
url.parse. Then we'd have one module for parsing (and unparsing) URL's
and one for actually using them.
Robert Brewer
[EMAIL PROTECTED]
___
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
point one of the urllib* modules can go away.
I like the above too, and I can't recall anyone talking about merging or
replacing urllib(2) in the multiple years I've been on this list. :) So
+1.
Robert Brewer
[EMAIL PROTECTED]
___
Web-SIG
ot;) in the new
cp-python-3 branch and be done.
Robert Brewer
[EMAIL PROTECTED]
___
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
your WSGI app, it will
still 404, sure; but that's your choice to use Apache or not. There's no
sense making WSGI a least common denominator, inheriting all the
limitations of all the existing web servers.
Robert Brewer
[EMAIL PROTECTED]
___
Web-SIG
Luis Bruno wrote:
> Robert Brewer wrote:
> > > IMHO [changing CP's wsgiserver to do decoding] is the wrong answer
> > Why?
> >
> Because then I'm stuck monkey patching every WSGI server (and/or stuck
> using my own URL dispatcher) so that I don't l
have to explain why you think the application should receive %XX encoded
URI's instead of decoded ones. What's the benefit? I only see a con:
every piece of middleware that cares has to repeat the decoding of
PATH_INFO and SCRIPT_NAME, wasting CPU and memory.
> Robert Brewer wrote:
>
#x27;ll just note
that I changed CP's wsgiserver to do decoding that very day. So I think
the answer is "yes".
Robert Brewer
[EMAIL PROTECTED]
[1] http://mail.python.org/pipermail/web-sig/2006-August/002230.html
___
Web-SIG mailing l
t;should logging be done by the application or
server?" is "neither". We need a component that covers the "everything
else" of WSGI; that is, the environment in which servers and
applications are instantiated, connected, started, stopped, and shut
dow
Chris Withers wrote:
> Robert Brewer wrote:
> > Apache will interfere, and try to re-apply the range to whatever you
> > emit. The only solution we've found so far is to tell the app to
> ignore
> > any 'Range' request header when running behind Apache, an
ignore
any 'Range' request header when running behind Apache, and just let
Apache have its way. See http://www.cherrypy.org/changeset/1319
Robert Brewer
[EMAIL PROTECTED]
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org
Graham Dumpleton wrote:
> On 27/11/2007, Robert Brewer <[EMAIL PROTECTED]> wrote:
> > Chris Withers wrote:
> > > Right, I'm curious as to how wsgi applications end up being
> > > multi-threaded or multi-process and if they are, how they share
> > >
. In a multiprocess environment, you can notify other
process with any of various forms of IPC or shared state mechanisms.
Robert Brewer
[EMAIL PROTECTED]
___
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
t part of the output?
Robert Brewer
[EMAIL PROTECTED]
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.488 / Virus Database: 269.15.0/1077 - Release Date: 10/18/2007
9:54 AM
___
Web-SIG mailing list
Web-SIG@python.or
;VARY', 'VIA', 'WARNING',
'WWW-AUTHENTICATE']
The only tricky one is Cookie, because e.g. Konqueror sends them on
multiple lines, but they're not foldable.
See http://kristol.org/cookie/errata.html
> Ngins does not do this (and I don't know what
Phillip J. Eby wrote:
> At 11:45 PM 8/24/2007 -0700, Robert Brewer wrote:
> >However, and here's the rub, if nextapp() raises an
> >exception, **self.response is never bound**, and
> >therefore we have no handle to the object we need
> >to close. Note that this is
ors"; we might want to make
that a MUST in future versions. Alternately, we could
require that every application provide its resource-
releasing endpoint via some means other than a successful
response. I'm sure you all can come up with other solutions.
Robert Brewer
[EMAIL PROTECTED]
__
threads, by the way. When people talk about
"per-thread" resources, that can usually be safely commuted to
"per-logical-process", where "logical process" encompasses threads,
processes (since they have a main thread, at least), and even tasklets
(Arnar Birgisson
out coordination between application/server
components and site-wide services, and I was using "process" redundantly
to mean "site". How about Web Site Event Bus instead?
Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]
___
start()
The only big difference being that IReactorCore.run also starts the main
loop, but that's assumed to be a separate step for WSPBus. Note that
IReactorCore.stop raises an error if not core.running, too.
I'll also note in passi
Phillip J. Eby wrote:
> At 02:17 PM 6/25/2007 -0700, Robert Brewer wrote:
> > Phillip J. Eby wrote:
> > > At 01:51 PM 6/25/2007 -0700, Robert Brewer wrote:
> > > For example, if an error occurs, isn't that an indication that the
> > > component is b
Chris McDonough wrote:
> On Jun 26, 2007, at 2:39 PM, Robert Brewer wrote:
>
> > Chris McDonough wrote:
> >> There are also non-webbish processes like postgres, mysql,
> >> etc. that
> >> need to be treated as "part of the application".
> &
ess controller that's calling bus.start, stop and
restart, there's nothing about the WSPBus that stops supervisor2 from
handling dependency graphs on its own. If process A has to *know* that
process B has been restarted, that's a problem (which could be
to do is make a common interface for such behaviors--if Apache has
native methods to achieve the desired behavior, then great! Wrapping
them in bus listeners (and subscribing a safe set of them by default)
allows deployers who aren't familiar with Apache to get their site up
and running faster.
Phillip J. Eby wrote:
> At 02:41 PM 6/25/2007 -0700, Robert Brewer wrote:
> >Phillip J. Eby wrote:
> > > Meanwhile, if you get a start call, you must be starting,
> right? So
> > > why worry about the state? It'd be simpler to just use
> > > "b
Phillip J. Eby wrote:
> Sent: Monday, June 25, 2007 3:09 PM
> To: Robert Brewer; web-sig@python.org
> Subject: RE: [Web-SIG] Web Site Process Bus (re-send)
>
> At 02:47 PM 6/25/2007 -0700, Robert Brewer wrote:
> >If I'm primarily a Pylons user, I'm used to start
1 - 100 of 169 matches
Mail list logo
