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.