Open Stack

Just to clarify, the reason I believe it is important to lay out
high-level design alternatives and their implications is because it
will help in making decisions about how the Message class is to be
changed.  In other words, the requirements for a class's behavior
might be drastically different, depending on whether it is a
replacement for an existing type (in which case all the possible
use-cases of the existing vs. new type need to be taken into
account) or it is going to be used in a new context, where adherence
to existing behaviors is not a factor.

My hope was that the design alternatives might be discussed,
possibly other alternatives proposed, and finally an alternative
chosen before proceeding with discussions about implementation
details.

Thanks,

John Warren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131016/ac33dbbe/attachment.html>