Makes sense to have a generic stream, I think.
We could have a factory method for the generic stream that only takes these arguments:
- stream name
- key finder class
or key finder string
- target PE
(finder string is in the todo list, we already have it in 0.4. the string is parsed to generate the finder class. It's an option for developers who dont' want to write key finder classes.)
Another thought is, should the Event base class be the generic event class? If the map is not created the overhead would be limited to one reference field. The benefit is that all events will be augmentable without having to subclass.
Why would we do this? because it provides an easy way to add meta-data or annotations to events. For example, for 2-way communication we need to send the origin address in the event over several hops. In NLP, we may want to add annotations to the event as it traverses several PEs. The annotator chain may change often, making it impractical to use dedicated event classes. The Map in base Event will make it possible to append these type of info using a simple pattern. (Of course this is more costly than using event classes but requires less boilerplate and fewer classes.) This design provide flexibility to use classes for static typing and speed or maps for flexibility or a combination of both.