acquaman/acquaman — Issue #241: String based data source
Author: dretrex
Created: 2012-02-27 17:25:41+00:00
State: open
Labels: Module - Acquisition, Module - Data Management

Short version: I need a data source that returns a QString from value().

Longer version: Due to the nature of XRF+XRD maps, it is intractable that all of the images be stored in a scan or in a data file. What is done currently is to trigger the CCD with a specific file path, name, and number to save each file to (ie: C:\\folder\file_num.spe). Then the file name without the path is saved in the data file as a pointer to the image for every data point.

Using the current framework, I could conceivably store the number in the data file and save the name inside of the scan configuration and then export it using a VESPERS specific file exporter, but in the rare case where you might have to go back into the raw data file, you would be missing valuable pointer information.

Another possibility is to extend AMNumber to also have a QString. I'm not a fan of this because it will add a fair bit of overhead to every other AMNumber, which is used extensively and effectively throughout acquaman. Even if we ensured that the string was null every time it didn't contain a string, I'm not certain if I want AMNumber to become a QVariant.

The final possibility I can think of is extending the data source framework to include strings. Since our data source framework is good and solid (for the most part) I don't think anything should be done to it specifically. Maybe add another class as a parent called AMDataSourceTemplate or AMDataSourceInterface that AMDataSource and AMStringDataSource would both inherit from. Then if this was done, another raw datasource (AMRawStringDataSource) would be required and need to work in the same way as AMRawDataSource. I don't know how practical or feasible this is currently (or ever) but I figured I'd bring it up.

I'd really like your guy's opinions on this because this is something I need for XRD maps, but would appreciate your two cents on how to go about it. I'm going to go with the first option for now because I need to get it to work sooner rather than later, but I'd like to get your thoughts on the best way to proceed in general. Unfortunately, this is a bit of a special case, but I could theoretically see other beamlines needing such a thing (CMCF if they didn't have their own good software, or maybe HXMA if they did XRD maps with their microprobe).