I am proposing a technical meeting amongst the developers to discuss in detail what needs to be done for
SctRodDaqRelease3. I propose looking at the components in turn, but starting with a system overview. Please feel free to add or change things --
MattSctRodDaqRelease 2.1
See also
SctRodDaqRelease2.1 - Matt will branch today.
- Aim for release this week
- Alessandro has a bug to fix in the archiving
- Dave will add a few things to the GUI - db uploaded
System
- Common IPC class - runtime debug control, status etc: RodCrateDAQ?? Bruce and Matt will investigate .. if not then go ahead
- ABCDModule changes: Some minor re-arrangement of used/unused. Matt will propogate through
- Testing (stress): We will work to merging dummy SctApi and SctTestApi?. This is potentially a lot of (hard) work. Some more on SystemTests
- Robustness: Very important! If we implement a common IPC class, then we will add features for causing random hangs and crashes.
- Error reporting: Look at how to structure MRS messages and Java reporting...if anyone has time, a job for someone here!
- File locations: Temporary files go in SCT_SCRATCH_DIR Long term files go in SCT_PERSISTANT_DIR Debug files go in TDAQ_LOGS_PATH
- Object lifetime: Alessandro will investigate how much time it will take to put TestResult object back into IS. Dave will change the GUI to delete only old files (>1 day?, not in current run?)
SctApi
CalibrationController
- Robustness, testing
- Potential bottleneck?
SctTestApi
- Direction, interface with SctApi: See above regarding testing
Configuration
- Old configurations
- Saving configuration
- BOC parameters: Defined in IDL
FittingService
- Changes to data model, log-liklihood fitting: Unlikely for release 3
AnalysisService
- Speed, more complex tests
- Raw data scans
ArchivingService
- Speed, direction
- Use cases
- Output size
SctGui
- Integration with IGUI: Do this, but only if time
- Configuration display and editing: Would be nice - put into a separate component so that it can be used from multiple places.