Hey Guys,
Here are a couple of comments:
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).
2) To clarify, do the Std* modules also contain some analyses that are
specific to that Sensor Data?
3) I completely agree with the hackyCommon module. But, where would the
admin commands and other things like new data alert go?
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.
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.
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...
thanks, aaron
At 03:43 PM 8/10/2005, you wrote:
I've finally come up with an approach to addressing the module-level
inconsistencies that have been growing in Hackystat over the past
year. Here's a description, the implementation of which would result in a
new major release/architecture for the system:
<http://hackydev.ics.hawaii.edu/hackyDevSite/doc/VersionSeven.html>
Please comment.
Cheers,
Philip
