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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
