It occurs to me that there is a very simple solution to this problem: have
the telemetry parser print out the documentation string associated wih the
chart (or the report) when there is any kind of failure associated with
chart (or report) invocation.
If the doc string was printed out as part of the error message, then the
Chart developer could provide documentation about not only what the chart
does, but what parameters it takes, _and_ what are currently legal values
for each of those parameters (i.e. what the streams/reduction functions
accept as strings.).
If that were available, then I think a lot, but not all, of the current
usability problems with chart/report parameter values would go away.
The fundamental problem with this approach is that if the reduction
functions/streams are changed in some way, then it is important to check
for a ripple effect in the chart/report documentation strings, so that they
continue to document the actual legal parameters.
In the long run, one could imagine a "smart" data flow analysis mechanism
for telemetry that can infer the potential values that an argument to a
chart definition takes based on the way it is used within the definition.
This, however, would be a Lot Of Work. I propose we go with the two line
solution first. :-)
Cedric: how hard would it be to start printing out the documentation string
associated with a chart or report when it is invoked and an error occurs?
Two lines of code?
Cheers,
Philip
--On Monday, September 25, 2006 12:07 PM -1000 Aaron Akihisa Kagawa
<[EMAIL PROTECTED]> wrote:
Hey Guys,
I've been trying some telemetry things and I realized that the telemetry
parameters are not very obvious. For example, the FileMetric-Chart. I
tried things like "SLOC", "LOC", etc. I had no idea that the valid
parameter was "sourceLines" (I suppose I should have known).
Furthermore, I wasn't provided any feedback that "SLOC" or "LOC" weren't
correct. Anyway, I found "sourceLines" in the SCLC data.
Anyway, I know that the telemetry language makes these parameters as
general as possible, but i think at the same time it makes it harder to
use.
thanks, Aaron