some notes to self extracted from source which probably won't
make a damm bit of sense.

alternative_implementation = """

taking into account the hierarchical construction of the zodb
allows construction of an event stream similiar to that used
by gui widgets, namely that of event bubbling.

"""

listener_registration_notes ="""
        # are there cases where we want to have one object listen
        # to the same event with multiple targets??
        # should probably make this configurable

        # an object can only register once for an event_type...
        # cannot register multiple filters to be called by the
        # same object this could be a problem with subclassing.
        # should reconsider after more real world experience.
"""

NEW_NOTES = """

add event proxy methods
add event heirarchy
"""

NOTES="""
Need to be able to go from
uid -> channel
channel -> uid
channel, uid -> filter

one weakness is removing event_types
won't remove registrations although
it will stop publishing.

to fix this prune_registrations
will do the required bookeeping,
why not include it, because its
an iterative journey through
all data structures maintained
by the channel.

filter checks, allow filters
to be python functions
from product modules,
... checkout external methods
for allowing it from extensions
subdir

event obj?
  should i wrap event sources
  to prevent assignment?
  (since assignment would be
  to a aq wrapper most likely
  this could be a leak
  source )

thinking about application integration
need to do some work for remapping
channels.

probably should be more forgiving
about duplicates registrations 
and silently fail...?

migration to Btrees 

propertymanager with configurable
transaction broadcasts and multiple
object registrations for eventtype with
different listener.
"""
