goalsandfeatures
[[goalsandfeatures]] last edit on Dec 24, 2006 11:14 PM by Anonymous

Cricket - Goals to achieve and new features for grapher.cgi


High-level goals


- Cleaner code structure
- Even more use of modules or functions for common processing tasks
- Seperate the perl code from HTML (Use HTML::Template)
This is partially done, HTML::Template is being used, see patches Tracker at the cricket project page, though
there is still some HTML being generated in the perl code.
- Leverage the perl knowledge of the cricket developpers
- Cleaner integration of holt-winter and mtargets
- Cross-platform
- leverage as much existing and functional code as possible.
Even though we aim to refresh the grapher, a majority of the code will be the same. We *are* talking a bout a 2400 line script!

Features


Features requested

- Integrated search functionality
- sort/filter objects by attributes 1
- online contextual documentation clickable in the interface 2
- Ability to display dynamic user selected logarithmic graphs.3
- Ability to select a user defined time range along with the traditional static time ranges. 4 (see cacti, with the time selection at the top)
- the ability to automatically generate tables that display current data source values in textual form
- ability to dump or display active thresholds alarms/warnings when browsing targets
- ability to recognize resolutions different from traditional every 5 minutes and display graphs correctly.
- more flexibility in image sizing (support for WAP and other small formats)
- acls on a per-user, per-group basis
- cookie based storage of display preferences with new default user preference page? (image size, format, legends, etc.)
- Another feature;
- graph based on alternate timezones.5

Other advantages


- We could then have people define CSS for cricket, web designers could go crazy on the interface and not worry about looking at oogles of obscur cricket code. A nice interface is not a bad thing.


How to proceed:


Development actions for next generation grapher for Cricket.


NOTES:


  1. Example: All devices auto-generated by genDevConfig, genRtrConfig, genCatConfig, systemperf, etc. Would have a common target called Chassis. This would indicate that anything in this objects directory and above should be treated as associated with this
object. Common sense, but to cricket everything is hiearchical and inherets from below in the tree. This way, it is easy for the grapher to treat these as objects. Easier to sort, filter, secure based on ACLs, etc. Nice clean implementation. For the rest
of the user created and maintained tree's, they can manually create the Chassis target with the basic attributes required. (Or it could be if any target has an attribute called isLeaf=true, then all targets in this directory and other contained in it are
considered the same object.)
What is the advantage you say? No need to maintain filesystem directory trees. The targets are displayed using the static view dictionnary or dynamically using filters directly from the grapher. This avoids stuff like: $CRICKET/config-tree/genRtrConfig/se


atle/router-1/targets
The seatle sub-dir is dropped, if you need to classify by location, or ISP or device type, you just put these as attributes in your Chassis target.
  1. Have little "?" question marks near titles, descriptions and interface elements. This question mark is a simple html link to the cricket documentation. This documentation would be included in html format in the distribution. Simple and clean.
  2. The user would select data values in grapher targets to be combined in the same graph. This graph would be a stateful diagnostic graph. The diag graph would be displayed in logarithmic format and all values could be converted to a % based on the max val


ues associated with the data value. This way all values are on a same scale. (Converting to a % could be an option.)
  1. Example of cacti user selectable time ranges.
http://alphawatch.alink.com/graph_view.php?action=tree&tree_id=2&leaf_id=28&select_first=true
  1. graphs are currently drawn in the time zone of the web server. extend this
to allow the time zone of the device (based on an attribute in the cricket
config) and alternatively the timezone of the browser.