On 26/06/07, Joseph Tate <[EMAIL PROTECTED]> wrote:
> On Monday 25 June 2007 22:48:47 Graham Dumpleton wrote:
> > Thus I believe a clear statement should be made that UNIX signals are
> > off limits to WSGI applications or components. I have no problem with
> > the underlying server upon which the
On Monday 25 June 2007 22:48:47 Graham Dumpleton wrote:
> Thus I believe a clear statement should be made that UNIX signals are
> off limits to WSGI applications or components. I have no problem with
> the underlying server upon which the WSGI adapter sits using them for
> its own purposes, however
On Monday 25 June 2007 20:32:38 Chad Whitacre wrote:
> All,
>
> >> Now I'm really confused. What is the idle state *for*?
> >
> > One concrete use case could be a test suite ...
>
> Is this also where Joe's comment in Dallas fits, namely, the case
> where you want to hold open a socket while resta
On 26/06/07, Robert Brewer <[EMAIL PROTECTED]> wrote:
> I'd like to continue talking about standardization on site-wide process
> state and services.
>
> As described more fully on my blog [1], I'm proposing we create a new
> spec for a simple publish-subscribe Bus to manage site-wide state
> trans
All,
>> Now I'm really confused. What is the idle state *for*?
>
> One concrete use case could be a test suite ...
Is this also where Joe's comment in Dallas fits, namely, the case
where you want to hold open a socket while restarting a child
process so as not to drop connections?
chad
___
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
> > > "before/during/after" messages the way Twisted does.
On 26/06/07, Ian Bicking <[EMAIL PROTECTED]> wrote:
> For instance, doesn't atexit work fine for exiting? (Not in mod_python,
> but I still don't know why it *shouldn't* work in mod_python.)
Exit functions registered by atexit don't work in mod_python for a few reasons.
First off is that if you
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 starting my websites with
> >"paster serv
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:
Seriously, though, this handles the notification but not the state
machine, which I think is critical to the effort. It also
>>> doesn't
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
> > "before/during/after" messages the way Twisted does. Your "block"
> > example could be r
At 02:47 PM 6/25/2007 -0700, Robert Brewer wrote:
>If I'm primarily a Pylons user, I'm used to starting my websites with
>"paster serve". In this case, paste.script would create a WSPBus object.
>[It's up to the Paste developers whether to distribute their own
>wspbus.py module, or to require one v
Phillip J. Eby wrote:
> At 04:42 PM 6/25/2007 -0500, Ian Bicking wrote:
>> Phillip J. Eby wrote:
>>> At 02:28 PM 6/25/2007 -0500, Ian Bicking wrote:
Potentially a Zope-style minimal event framework would work. Maybe
something like:
send_signal(signal_name, signal_data)
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:
> > >Seriously, though, this handles the notification but not the state
> > >machine, which I think is critical to the effort. It also
> > doesn't do any
> > >error-handlin
At 04:42 PM 6/25/2007 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>At 02:28 PM 6/25/2007 -0500, Ian Bicking wrote:
>>>Potentially a Zope-style minimal event framework would
>>>work. Maybe something like:
>>>
>>> send_signal(signal_name, signal_data)
>>> subscribe(signal_name, listener)
Phillip J. Eby wrote:
> At 10:57 AM 6/25/2007 -0700, Robert Brewer wrote:
> >This should be a collaborative effort, and I'm very open to
> >discussion at all levels of detail. Even if this flies at the highest
> >conceptual level, there are still several things I know of
> >we would need to nail d
Jim Fulton wrote:
> On Jun 25, 2007, at 4:51 PM, Robert Brewer wrote:
>
> > Benji York wrote:
> >> Robert Brewer wrote:
> >>> I'd like to continue talking about standardization on
> >> site-wide process
> >>> state and services.
> >>
> >> Perhaps zope.event would be a good fit.
> >> http://svn.zop
Jim Fulton wrote:
>> All 4 lines of it? ;)
>>
>> subscribers = []
>>
>> def notify(event):
>> for subscriber in subscribers:
>> subscriber(event)
>>
>> Seriously, though, this handles the notification but not the state
>> machine, which I think is critical to the effort.
Ian Bicking wrote:
> Phillip J. Eby wrote:
>> At 02:28 PM 6/25/2007 -0500, Ian Bicking wrote:
>>> Potentially a Zope-style minimal event framework would work. Maybe
>>> something like:
>>>
>>> send_signal(signal_name, signal_data)
>>> subscribe(signal_name, listener)
>> That was what I was wo
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
> "before/during/after" messages the way Twisted does. Your "block"
> example could be replaced by waiting for the "after" message of the
> des
Phillip J. Eby wrote:
> At 02:28 PM 6/25/2007 -0500, Ian Bicking wrote:
>> Potentially a Zope-style minimal event framework would work. Maybe
>> something like:
>>
>> send_signal(signal_name, signal_data)
>> subscribe(signal_name, listener)
>
> That was what I was wondering, too, except I wa
On Jun 25, 2007, at 4:51 PM, Robert Brewer wrote:
> Benji York wrote:
>> Robert Brewer wrote:
>>> I'd like to continue talking about standardization on
>> site-wide process
>>> state and services.
>>
>> Perhaps zope.event would be a good fit.
>> http://svn.zope.org/zope.event/trunk/src/zope/event
Phillip J. Eby wrote:
> At 01:51 PM 6/25/2007 -0700, Robert Brewer wrote:
> >Seriously, though, this handles the notification but not the state
> >machine, which I think is critical to the effort. It also
> doesn't do any
> >error-handling for misbehaving subscribers, so not all
> subscribers are
Robert Brewer wrote:
> All 4 lines of it? ;)
A thing of beauty, isn't it.
In all seriousness, it's served Zope 3 well for quite some time.
--
Benji York
http://benjiyork.com
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/si
At 01:51 PM 6/25/2007 -0700, Robert Brewer wrote:
>Seriously, though, this handles the notification but not the state
>machine, which I think is critical to the effort. It also doesn't do any
>error-handling for misbehaving subscribers, so not all subscribers are
>guaranteed to run if there's an un
Benji York wrote:
> Robert Brewer wrote:
> > I'd like to continue talking about standardization on
> site-wide process
> > state and services.
>
> Perhaps zope.event would be a good fit.
> http://svn.zope.org/zope.event/trunk/src/zope/event/README.txt
> ?view=markup
All 4 lines of it? ;)
s
Phillip J. Eby wrote:
> At 10:57 AM 6/25/2007 -0700, Robert Brewer wrote:
> >This should be a collaborative effort, and I'm very open to
> >discussion at all levels of detail. Even if this flies at the highest
> >conceptual level, there are still several things I know of
> >we would need to nail d
At 02:28 PM 6/25/2007 -0500, Ian Bicking wrote:
>Potentially a Zope-style minimal event framework would work. Maybe
>something like:
>
> send_signal(signal_name, signal_data)
> subscribe(signal_name, listener)
That was what I was wondering, too, except I was thinking it would be
sufficient
Robert Brewer wrote:
> I'd like to continue talking about standardization on site-wide process
> state and services.
Perhaps zope.event would be a good fit.
http://svn.zope.org/zope.event/trunk/src/zope/event/README.txt?view=markup
--
Benji York
http://benjiyork.com
_
Phillip J. Eby wrote:
> At 10:57 AM 6/25/2007 -0700, Robert Brewer wrote:
>> This should be a collaborative effort, and I'm very open to
>> discussion at all levels of detail. Even if this flies at the highest
>> conceptual level, there are still several things I know of we would need
>> to nail do
At 10:57 AM 6/25/2007 -0700, Robert Brewer wrote:
>This should be a collaborative effort, and I'm very open to
>discussion at all levels of detail. Even if this flies at the highest
>conceptual level, there are still several things I know of we would need
>to nail down:
>
> * States. For example,
I'd like to continue talking about standardization on site-wide process
state and services.
As described more fully on my blog [1], I'm proposing we create a new
spec for a simple publish-subscribe Bus to manage site-wide state
transitions (start, stop, etc.) and connect application components wit
31 matches
Mail list logo
