Overview | Releases | Download | Docs | Links | Help | RecentChanges

PhoneMeeting2

16/3/2004

Issues:

How to proceed when a module dosen't behave well (e.g. LV trip)

note : Requires modification to DSP code to get histogramming to continue when errors are encountered!

Possible solutions for downstream analysis:

  1. Modifies IS TestData to include list of bad modules, to be added to by API
    1. is this sufficient for all scenarios?
    2. Does this need to be done on a per-test basis? Current status probably insufficient.
  2. API produces dummy RawScanResult with some sort of status info
    1. a bit nasty? (assuming something like solution (1) is used above!)

Matt to add status information

Ownership/deletion of data

Problems with current solution

  1. General philosophy is that GUI should be farily distinct from the nasty low-level stuff.
  2. If two or more GUIs are running (as was the case in Oxford yesterday), could cause synch problems.
  3. What does GUI do if services are busy() Analysis:
  4. Data is really shared between many processes.
  5. Needs some sort of idea of whether to expect data of various types
  6. Some data will be e.g. file cache of retrieved data requested and used by GUI.

Suggestions

Postponed!

Viewing of ArchiveData

Largely Dave and Alan to discuss. Archiving to move to CondDB? in Release 4 - work required here.

Alan and Dave to discuss

Online version

Raw Scans

Alan and bruce to investigate, starting with publishing raw