The purpose of this memo is to provide some talking-points on the subject of properties / auxiliaryInfo for AtomSetCollection and AtomSet objects.
The file readers read data from specific file formats. Some characteristics are common to many/all file types ... e.g. atom locations. Other characteristics are used by only a few file types ... e.g. symmetry/space group data. We previously used atomSetCollectionProperties and atomSetProperties to store this "extra" data. One characteristic of Properties is that both keys and values are restricted to String. In the process of implementing some more advanced features, Bob found this too limiting. He added support for a Hashtable object called auxiliaryInfo. The Hashtable object allows one to store more complex data structures. Below are some of my questions and thoughts in random order: * Properties are nice to use because you can guarantee that you are going to get back a String * We need to be careful about passing around complex data structures. It is a slippery slope that can lead to overwhelming complexity. * The boundary between the readers and the viewer should be very strong and very well defined. This was done by design, because it decreases complexity. Complicated data structures should not cross this boundary. (Strong fences make good neighbors) * I can believe that limiting ourselves to "strings" is too complicated. * I am not opposed to allowing a set of primitive data types to cross the boundary ... boxed primitives + arrays of primitives. I would have a hard time accepting any data structures more complicated than that. Note that I have excluded any aggregate data type (class) other than arrays of primitives. * If there *were* a need to support something more complicated, then it would have to be defined in the API ... in the same manner as JmolAdapter.AtomIterator, JmolAdapter.BondIterator, and JmolAdapter.StructureIterator. * It isn't clear to me that the "auxiliaryInfo" data structures should be directly exposed to client programs, Java or JavaScript. I have doubts. * I would be useful for me to get some understanding of the types of data that we would expect to come through this interface in the future ... symmetry vibration/resonance stuff (?) Q: What other kinds of data would we reasonably expect to want to read from data files within the next 2 years? * I need to better understand the distinction between which properties are "AtomSet" and which are "AtomSetCollection" * There is an advantage to using a simple Hashtable for storing this data. Simplicity * There would be an advantage to defining our own dictionary data structure ... control+validation of keys+values and inheritance of AtomSetCollection properties through AtomSet Let's talk. Miguel ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
