DataResourcePlugin simplification opportunity

[dylanmcreynolds]

While trying to extend from the DataResourcePlugin class, I noted that it has a lot of model-ish methods in it. There is also the DataSourceListModel class, which has a dependency to DataResourcePlugin and turns around creates member variables linked to the DataResourcesPlugin classes model-ish methods. So essentially, the DataResourceModel ends up being just a proxy to the DataResourcePlugin's rich modelly-goodness. It was hooked up this way because there is a headless mode and DataResourceModel extends from QT classes, so the Plugin class has to have data-only abstraction without QT.

Talking with Ron about this, we think this might be an opportunity for simplification. It might be nice if the API in the DataResourcePlugin defined just the interactions between the plugin and Xi-CAM, centered around pulling data from the plugin and pushing data into the plugin. Then the plugin could setup whatever MVC structure makes sense for it.

[dylanmcreynolds]

This was mostly addressed with 28e1c9b . @ronpandolfi , should we close this, or is there something you'd like to do with other databrowerplugins?