<br><br><div class="gmail_quote">On Tue, Nov 27, 2012 at 12:15 AM, Jiang, Yunhong <span dir="ltr"><<a href="mailto:yunhong.jiang@intel.com" target="_blank">yunhong.jiang@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">>       > In previous API designs I have always found it easier to have<br>
>       > well-defined classes passing data between the layers, rather than<br>
>       > accepting variable, undefined, arguments like this. The new<br>
>       > developer coming along to add a feature has far less work to do when<br>
>       > figuring out what data to emit as output or take as input to a new<br>
>       > plugin, and it almost always turns out to be easier to create<br>
>       > components that can be recombined in unexpected ways because of the<br>
>       > standard data structures. Using a class also means fewer changes<br>
>       > when new fields are added (because you only have to find where they<br>
>       > are constructed, not every call to a plugin) or removed (because you<br>
>       > can provide a backwards-compatibility @property method).<br>
><br>
><br>
>       That's fair enough, hopefully we can achieve the strongly-typed<br>
>       interaction between pollster and transformer without an undue<br>
>       proliferation of new types.<br>
><br>
><br>
><br>
> The types will exist by virtue of the interfaces existing. I'm just suggesting that<br>
> we create them in a way that makes them to easier to document. :-)<br>
<br>
</div>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.<br>

<br>
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.<br></blockquote><div><br></div><div>Transformers that don't deliver data right to publisher should probably emit the same type of object they receive so the order of the pipeline isn't important.</div>
<div><br></div><div>Using dictionaries is still going to require the transformer to know what it is getting and what it should emit. The difference is the developer has to know what keys to include and what names to use, and so that has to be documented. Using a class with a well-defined constructor gives us that documentation automatically.</div>
<div><br></div><div>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br>