--On Wednesday, August 10, 2005 4:40 PM -1000 Aaron Kagawa <[EMAIL PROTECTED]> wrote:
1) There probably should be a mechanism to ensure that a configuration that contains a specific sensor should also contain its associated Sdt* module. Its not a programmatic dependency but it is an functional dependency (if that makes sense).
That's already present. For example, the hackyAnt module (which contains sensors for JUnit, JBlanket, etc.) will depend upon SdtUnitTest, SdtCoverage, etc.) This will be enforced in build.xml.
2) To clarify, do the Std* modules also contain some analyses that are specific to that Sensor Data?
Yes, they definitely can, as long as those analyses don't depend on any SDTs other than the current one.
3) I completely agree with the hackyCommon module. But, where would the admin commands and other things like new data alert go?
If they are SDT independent, then they can go in hackyCommon. If they depend upon a single SDT, then they can go in the associated Sdt* module. If they depend upon more than one SDT, then they can go in hackyStdCmd.
4) While I agree that the version 6 architecture isn't very scalable for the long term, one thing that it was good for was experimentation. It seemed that we (Cedric, Hongbing, Christoph and I) were able to go into our own little word and hack something together. I would hope that Version 7 will allow the same possibility.
Absolutely. If you look at hackyStdExt, hackyTelemetry, and HackyInstaller, you see the same pattern: a module that is initially implemented with a combination of generic infrastructure plus SDT-specific functionality (because that allows "our own little world"). Once things settle down, then you don't need your own little world and the system architecture is best served by splitting things out.
In my view, hackyStdExt, hackyTelemetry, and HackyInstaller are now "mature" enough to be reorganized. But I certainly support people creating modules in future that start out combining generic and specific while they are experimenting. This seems to be a natural evolutionary cycle in hackystat, and I'm not proposing that we should stop doing it in future.
A couple of random thoughts: 1) I think Jupiter could use a redesign. I was thinking about Cam's Europa system and that he ripped out code from Jupiter and used it in his system. Actually, if Jupiter was designed in a MVC fashion, then Cam would just be implementing a new View.
Interesting.
2) at some point I could imagine that Hongbing's Stream analysis would reach a certain similarity to telemetry reducers, in that it could be a higher level component that Sdts could be implementing...
Very interesting. Hongbing, your thoughts? Cheers, Philip
