Some ideas on AMC13 HyperDAQ code structure.

Currently have amc13::Status with Report() and set/get methods for HTML, BareHTML and LaTeX. Suggest the following:

Changes in existing Status class

  • Add new SetOutputMode() as an improvment over SetHTML() etc (keep old methods for compatibility)
  • Add new methods for accessing separate sections of output:
    • ReportHeader() for header information required to start output document
    • ReportStyle() for CSS or other similar information which affects rendering
    • ReportBody() for main content (with optional table specifier)
    • ReportTrailer() for trailer information required to terminate output document
    • Each of the above would have two prototypes, one outputting to a stream, the other returning a string
      • void ReportHeader( int level, std::ostream...)
      • std::string ReportHeader( int level...)
  • Existing Report() would use above to output a complete report
  • Add new methods to allow access to data using the table/row/column addressing scheme (maybe the SparseCellMatrix class already provides this?)
    • GetTableList() method to retrieve a vector of defined tables
    • GetTableRows() and GetTableColumns methods to retrieve a list of table rows/columns
    • GetCell() method to get the Cell() given table/row/column

Questions:

How to handle things like the TTC command history, L1A history, data dump etc?

Could in principle be done using the existing structure by adding them as tables which don't show in the normal status display, but could be retrieved by table name. How would this work for a variable-length list? Is it worth adding this to the address table?

Eric is going to work on this.

How to integrate Daniel's unpacker code for data display?

How to handle subdetector-specific display information?

Dan will discuss both of these with Daniel

Do we want to provide a simple stand-alone framework to test this code without having to run HCAL xDAQ?

Should eventually move all web display code from the xDAQ to a separate class, and build a stand-alone CGI executable for testing.

-- EricHazen - 11 Sep 2015

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 11 Sep 2015 - EricHazen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2023 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback