Open Stack

> 	> In previous API designs I have always found it easier to have
> 	> well-defined classes passing data between the layers, rather than
> 	> accepting variable, undefined, arguments like this. The new
> 	> developer coming along to add a feature has far less work to do when
> 	> figuring out what data to emit as output or take as input to a new
> 	> plugin, and it almost always turns out to be easier to create
> 	> components that can be recombined in unexpected ways because of the
> 	> standard data structures. Using a class also means fewer changes
> 	> when new fields are added (because you only have to find where they
> 	> are constructed, not every call to a plugin) or removed (because you
> 	> can provide a backwards-compatibility @property method).
> 
> 
> 	That's fair enough, hopefully we can achieve the strongly-typed
> 	interaction between pollster and transformer without an undue
> 	proliferation of new types.
> 
> 
> 
> The types will exist by virtue of the interfaces existing. I'm just suggesting that
> we create them in a way that makes them to easier to document. :-)

IMO, from another view, if we have the pipeline idea, there is not that much difference of transformer and publisher, except the publisher will end the pipeline. Every components in the pipeline simply passing the data down the pipeline, and the next item in the pipeline decide continue, or publish.

If we take this idea, the type can be more flexible, we can have the type keep the type_name, so that the transformer can handle it.