Actually, I'm sure Christoph Aschwanden would agree that Human Stat data, demographics, experience, and other groupings, were exactly what our idea ( http://csdl.ics.hawaii.edu/Publications/MasterList.html#csdl2-02-10) was based on.
Whoops, sorry about that! Hackystat is getting so old that I'm starting to forget all the things we did in the past! I've updated the paper to include this link.
Should the Compile and Edit types be Build:Compile and Edit:StateChange? Furthermore, should the types be prefixed by "HPC"? I'm not sure what happens if I have HPC and Zorro DevEvent entries mixed together. They have different pMap data and one would hope that you wouldn't have to check the optional attributes to determine the type of particular DevEvent entry.
I agree, this is something we need to think harder about. Perhaps that there should be an optional (required?) field called "event-family", with values like "HPC", "Zorro", etc. that enable analyses to quickly filter out events not of interest to them.
Then, there's the question of how to modularize things correctly on the client side. Some alternatives:
(1) Each "family" of events are packaged in their own module: hackySensor_Eclipse_HPC, hackySensor_Eclipse_Zorro, hackySensor_Eclipse_ECG, etc. This makes it easy to install and enable/disable a family of events using hackyInstaller. It also makes it easy for third parties to add their own module with their own set of custom events to be collected with Eclipse. The disadvantage is the potential for redundant code in the modules. One idea would be to make the "hackySensor_Eclipse" module a high-level interface to Eclipse for use by hackySensor_Eclipse_*. hackySensor_Eclipse would not be a sensor itself in this case, but rather provide an API that makes the writing of something like hackySensor_Eclipse_HPC very, very easy.
(2) Provide all event types through hackySensor_Eclipse, with some property settings to enable/disable specific event settings. At first glance this doesn't seem nearly as attractive to me as (1).
What do people think? Cheers, Philip
