Events, Frameworks and FUD

First, a little history. Lets start with the question, "Why doesn't Plone have an event system?" For an event system to really work I would suppose that it needs to be used in all or at least many of the major system in play in a given system. In Plone this would mean that CMFish things would need to fire and consume the same events as the rest of Plone, as the rest of Archetypes, as the events as third party products. In other words an events solution needs to be arrived at from the lowest layers or boil the ocean. Well years into this project none of the lower stack levels have put forward anything usable and nothing has been promoted from application land. Does this mean that no one has tried? Of course not, many have, too many have. In fact in Plone land alone we had 3 different 'event systems' of various size and scope in play for the last few years.

Because no previous effort has won enough development mindshare or devotion to become 'the' event system used in the Plone stack people have by and large been reluctant to use any of them till a winner emerges. We've had a stalemate. To make matters worse the promise of Zope 3 and its clean refinement of the Zope architecture and stack has in many ways halted significant progress in Plone land. We are left making incremental improvements to exiting feature without breaking any new ground. And guess what... That's OK, Zope 3 is better and we have quite a few people waiting for it, experimenting with it, and even a few deploying on it.

Back in Plone land though, no events... oh we can abuse the catalog hooks all we want, those are almost in the right place that we can keep adding things to them to keep extending the system but this is no answer. As a result, it was my impression that the term Event has a certain negative stigma around it, a kind of false promise. For marketing reasons I looked for another term. From a technical perspective events as they are dealt with via the catalog hooks have a particular semantic and a real lack of flexibility and yet still some people see these as events. For technical reasons I sought another term.

If I used the term framework I apologize. That's the flavor of the day word for, "I'd like to be victimized (by the community I am trying to help)" and I should know better than to toss it about, but I don't think I ever said that. The code in question is a pluggable routing class for event payloads and a tool that can manage subscriptions persistently. We recently tried to update it to use Five events for payloads and install a bridge between Z3's 'notify' API and the 'fireEvent' call that makes sense in a Z2 Acquisition hierarchy. That's it.

Its small, its using Z3 concepts and code where we can and we asked for feedback. That offer is still open.