On 28/06/07, Robert Brewer <[EMAIL PROTECTED]> 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
Chris McDonough wrote:
> I think I'm mostly confused by the name "process bus" because it
> seems like the primary use case for something like this is where all
> of the applications share the same process space and are all written
> in Python. Am I right? If so, maybe a different name is i
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
> desir
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 broken? Masking the failure just makes it
> > > l
On Jun 26, 2007, at 5:07 PM, Robert Brewer wrote:
>> I think I'm mostly confused by the name "process bus" because it
>> seems like the primary use case for something like this is where all
>> of the applications share the same process space
>
> I don't see why it should be limited by that. The pri
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".
> >>
> >> I handle this currently by running all of the proc
[Graham Dumpleton]
> First comment is about WSGI applications somehow themselves using
> SIGTERM etc as triggers for things they want to do. For Apache at
> least, allowing any part of a hosted Python application to register
> its own signal handlers is a big no no. This is because Apache itsel
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".
>>
>> I handle this currently by running all of the processes related to a
>> specific project und
Chris McDonough wrote:
> There are also non-webbish processes like postgres, mysql, etc. that
> need to be treated as "part of the application".
>
> I handle this currently by running all of the processes related to a
> specific project under a process controller (which happens to be
> imple
On Jun 26, 2007, at 1:04 AM, Graham Dumpleton wrote:
> In Apache changing the certificates would need a complete restart of
> everything. Because the child processes aren't privileged they would
> not be able to trigger the main server to do so. This actually gets to
> one of my reservations about
Graham, thanks for this and the previous post. I've had these issues in
mind while designing the current bus, but you raised them far more
eloquently than I could have.
Graham Dumpleton wrote:
> The only way we may know is to start stepping through specific uses
> cases one at a time, not even wor
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 start
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
42 matches
Mail list logo
