CySession.xml is the file to save current states of Cytoscape session.
The following information will be stored in the XML document:
 1. List of networks opened in current session.
 2. States of Cytopanels 1~3.
 3. Network Tree structure (shown in Network Panel in CytoPanel 1).
 4. Session ID
 5. Annotation (node/memo) for the session
 6. Selected/Hidden nodes and edges
 7. Plugin state (This topic should be dicussed with plugin writers)

=== Plugin State ===
7 is more complicated than others.  First of all, we need to create new signals called "SESSION_SAVE" and "SESSION_LOAD" to tell plugins that session save/load command is executed.  To simplify this process, we may need a standard for plugin state saving mechanism.  One possible solution is:

 * Create a schema for each plugin to describe its state.
 * Use JAXB to create Java code to access plugin states in an XML file.
 * Session Saving class copies state/data xml files for each plugins, and zip them into .cys file.

In any case, plugin writers are responsible to create readers/writers for their plugin state/data files.  One standard they must follow is make method to catch signal generated by save/load session classes.

----
Discussion:
 * GaryBader - Feb.7.2006 - For plugin state, we should also be careful that plugin save/load functionality doesn't negatively affect Cytoscape load/save functionality. For instance, a plugin could have a bug that causes an infinite data write loop that prevents Cytoscape from saving a file. Maybe this could be handled by setting a default limit on space and time of the plugin save/load method. It could be overriden by plugin writers who really need to write large files, but they would have to specifically reset the limit, which might make it easier to avoid bugs.  Maybe it's not even worth implementing any limits until it becomes a problem and instead just add it to the documentation.