Changes between Initial Version and Version 1 of 2014-09-30

Timestamp:

Sep 30, 2014, 12:52:59 PM (11 years ago)

Author:

Tom Goddard

Comment:

--

2014-09-30

@@ +1 @@
+= 30 September 2014 meeting, 11:00 - 12:15 =
+
+== Attendees ==
+
+Conrad, Sam, Eric, Greg, TomG
+
+== Agenda ==
+
+Should our APIs access only one global session data instance or allow multiple session data instances?
+
+== Action Items ==
+
+Greg - Propose a session data API for Thurs Oct 2 meeting
+
+== Results ==
+
+**Support multiple session data objects**.
+Discussed whether multiple Chimera sessions within the same Python process should be allowed, or only a single session.
+Decided to support multiple sessions at the Python API level.  This will allow the possibility of command-line and GUI tools
+to compare sessions (Sam suggested a tabbed user interface), but we do not plan to implement those user interfaces in the near term.
+
+**Message logging is per-session**.
+Discussed whether logging (errors, info, status) would be global or whether a routine that wanted to issue a log message
+would have to have a logger passed as an argument (or for methods the instance could have a logger attribute).
+Agreed that routines that want to log will take a logger argument that comes from a session.  In other words, logging
+will be per-session and not global.
+
+**Exception handling**.
+Discussed how Python exception handling would be logged.  Which session would log the exception?  Possible solutions
+were that all sessions would log the exception, or the most recently created session.  Didn't reach a conclusion on how
+this will be handled.
+
+**Preferences are global**.
+Discussed whether preferences are global or per-session.  Decided they are global.  Each session can have its own state
+setting such as background color blue, while the preference setting that determines the initial background color is a
+global setting. Discussed the open file history list -- does every session add to the same list?  Yes.  File history is like other
+hidden preference categories (in Chimera 1 lingo) where preference data is implicitly saved without the user pressing
+a Save Preference button.  Eric suggests that each tool save its preferences in a separate file so that every preference
+change does not result in resaving all preferences.
+
+**Trigger notifications**.
+Started discussing whether Chimera 1 triggers would be used in Chimera 2 and how they would operate with multiple sessions.
+Decided to defer this question to another meeting.
+