Early in the design there was a "datastore" singleton which served as the manager for the collection of data sources and isolated the rest of the application from the details of data sources. However, the notion of a composite datasource is generally useful, so it makes sense to add a subclass of data source which is a composite of other datasources. Thus the datastore class can be replaced by an instance of a composite data source class. Using a composite datasource, the set of datasources in use by an application can be divided arbitrarily into a hierarchy. For a display application, flight datasources might be grouped into a single project datasource, or datasources might be grouped into similar scientific scenarios, however makes the most sense for the user. The hierarchy provides a convenient namespace for browsing and managing the datasources: flight "rf03" for BAMEX might have the full name "bamex/rf03". From this qualification follows a natural way to distinguish variables with similar names from different datasources: "bamex/rf03/tdry" versus "soundings/kbco/tdry".
So DataSource needs an interface to allow the application to browse the DataSource hierarchy. The GUI uses that interface to generate a tree view of the DataSources which the user can browse. When a user chooses a DataSource, a second window updates with the list of variables available from that source. This is analagous to the current scheme for netcdf files, except now a source may be a SQL database instead of a netcdf file.
To simplify the exchanging of lists of DataSets in the datastore API, there is a distinct DataSetList type rather than just using vector<DataSet>.
Requirements
Make sure multiple plots and windows can share the same datastore. So need to diagram how datasets might provide different 'shapes' of data, eg, 1-d time series, 2-d time series, asynchronous. Asynch data violates the assumption of being able to detect when a dataset is incomplete to plot a particular time window. A dataset will have to have some smarts to keep track of what time periods it has data for from previous requests, so that any attempt to request data which covers a gap forces a new request for data in that gap.
Support non time-dependent data like GIS or other static curves (calibration curves?) and overlays. The explicit domain for a data request right now is time (start and stop times), maybe that structure can be generalized now, early in the design, for data which must be selected on more than one dimension or a non-time dimension.