Blinker in a web framework/application

[Randy Syring]

Jason,

I have been looking a bit at Blinker for use in a web framework. I
have a problem, or so I think, that I would like to share with you to
see if you can give some pointers with respect to Blinker.

My framework can have multiple applications running in a single python
process. Each application has its own set of plugins in its source
but can also share plugins that are installed as Python packages. I
am thinking that each plugin and application will have an events
python module that will define the events it wants to listen for from
the main framework's code.

Applications are initialized one after the other. The problem that I
am foreseeing is that events are going to get fired globally, a
"request received" event for instance, and the app that the request is
for will send a signal for that event. But the event listeners for
that app, as well as any other apps, would get signal. So, basically,
I need a "context" for my listeners. I was thinking something like:

from blinker import signal, setcontext

def sub_for_app_a(sender):
print("Got a signal sent app A")

def sub_for_app_b(sender):
print("Got a signal from app B")

ready = signal('ready')

setcontext('appa')
ready.connect(sub_for_app_a)

setcontext('appb')
ready.connect(sub_for_app_b)

>>> ready.send()
"Got a signal from app B"

setcontext('appa')
>>> ready.send()
"Got a signal from app A"

For my purposes, setcontext() would also need to be thread safe.

I would appreciate any thoughts you might have on this.

[Randy Syring]

Upon further review, it looks like I just need to have different
namespaces for my signals. I implemented my own signal() and it looks
like this:

from blinker import Namespace

from pysmvt import ag

def signal(name, doc=None):
return ag.events_namespace.signal(name, doc)

"ag" is a stacked proxy object, so it is always referencing the
current application and is thread safe. Therefore, signals are saved
and retrieved at the application level. I have done some testing and
it looks like this works well. Do you see any problems with this
solution?

Thanks.

[jason kirtland]

Hi Randy,

Another option that may work for this scenario is to use the 'sender'
subscription system as the namespacing / context for these signals.
With the app as the sender argument, receivers can use that to look up
app-specific information, or restrict signal reception by connect()ing
only to the apps of interest. Multiple connect()s on a
signal/receiver pair with different sender filters are very
inexpensive in Blinker.

-J

> --
> You received this message because you are subscribed to the Google Groups "discorporate-tools" group.
> To post to this group, send email to discorpor...@googlegroups.com.
> To unsubscribe from this group, send email to discorporate-to...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/discorporate-tools?hl=en.
>
>