RowanChristmas - 10/03/05 -- {{{CyData/Definition}}} have support for events already. If we make yet another layer of events there will be 2, possibly incompatible event frameworks to use.  To me this points to just extending {{{CyData/Defintion}}}.

EthanCerami - 10/4/05 -- On the first issue, I agree that having two interfaces for listening to events is potentially very confusing, and {{{CyDataListener}}} seems to provide everything we already need.  Maybe we should just stick with it, and simplify our lives.  However, it is also possible that we can continue to use {{{CyDataListener}}} even if we embed {{{CyData}}} in {{{CyAttributes}}}.  For example, we could set up {{{CyAttributes}}} with no separate {{{addListener()}}} methods.  If a user wants to listen to events, they simple call {{{getCyData()}}}, and then register their listener with this class directly.    

NeriusLandys - 10/04/05 -- Here is the reason why we decided that the listener interfaces defined in the {{{CyData/Definition}}} framework are not optimal for using withing {{{CyAttributes}}}}:
{{{CyAttributes}}} introduces the concept of a list of attribute values.  Internally, the list of values will be using a {{{CyData}}} structure which maps "0" to the first value, "1" to the second value, and so on.  If {{{CyDataListener}}} is used to receive events on "list" attributes, the programmer will need to know this internal detail.

EthanCerami - 10/5/05 -- Subgroup (Nerius, Iliana, Ethan) agreed to just go with the existing event framework provided by {{{CyData}}}, rather than creating a second, parralel event framework just for {{{CyAttributes}}}.  Group also agreed to change the name of {{{CyData}}}.  Current plan is to rename it to {{{MultiHashMap}}}, but Iliana likes {{{RecursiveHashMap}}}.