SensorShell has a constructor that allows you to pass in a boolean that, if set to false, disables offline data storage/retrieval. Both hackyCVS and hackyJira need to use that constructor. This is because the current implementation of offline data storage is designed around the assumption that the sensor.properties file can be used to determine the user and host.
This is not the case for the CVS and Jira sensors, which use the usermapping approach to determine user and host. Thus, the offline mechanism won't work correctly. It is thus best to explicitly disable it in the sensor so that it's clear that this utility is not being used in this case.
This brings up a new issue: what happens when the server goes down, since offline data storage will not work?. We need to think about the design implications of this, particularly with respect to the Jira sensor. It is probably unsafe to assume that the current 'active' approach to sensing will provide a 'complete' record of activities in the Jira server. This impacts strongly on the kinds of analyses we can do on this data.
Aaron, Cedric and I were talking about adding a 'snapshot' style of data collection to the Jira sensor that would send data regarding only the current open issues once a day. This would be one way to ameliorate the impact of our inability to guarantee complete records of jira server activity, and support a telemetry stream on open issues for a given project (which is probably the most useful analysis we could provide).
Cheers, Philip
