[Libmetrics-devel] Re: libmetrics

[Tim N. <arc...@we...>]

On Tue, 12 Apr 2005, Luke Kanies wrote:

> On Mon, 2005-04-11 at 11:20 +1000, Tim Nelson wrote:
>> On Fri, 8 Apr 2005, Luke Kanies wrote:
>>
>>> On Fri, 2005-04-08 at 14:49 +1000, Tim Nelson wrote:
>>>>  	Another idea -- we should pass the name of the metric into the
>>>> function it calls.  In many cases this would be useless, but it would mean
>>>> that we could call the same function with different names and it would
>>>> return different values (this would have a variety of uses, and is
>>>> necessary for my distro thing).
>>>
>>> Huh; yeah, that could solve the problem that we're having.  Require an
>>> argument, and for most cases that argument would be worthless, but for
>>> the case of disks (or other systems with more than one value) it would
>>> get that value.
>>
>>  	It would also mean that I could create a metric for each variable
>> in my variables system (dynamically, depending on the contents of the
>> config file), and point them all at the same function, but with different
>> names :).
>
> I think I'm with you here...

 	Maybe not; I was assuming (dumb :) ) that you'd flicked throught 
the distropicker code I sent you.  It uses the GNU functions hsearch_r eg. 
al (man hsearch_r) to store a bunch of variables which it extracts from 
eg. /etc/redhat-release.

>>> Do we create a separate metric for every disk?  That means adding
>>> metrics at run-time (which is fine, but not currently done).  If we
>>> don't do that, then how do we know that the metric is able to give us
>>> more information?
>>
>>  	That's not what I was thinking :).  I think between the idea
>> above, and the va_start one, we should have it covered, though :).
>
> But now I'm lost.  Currently, each metric returns a single value, not an
> array of values.  So, following this scheme gives us a separate metric
> for each disk (even if the metric is the same function but just a
> different name).  How else could we do this?
>
> And can you explain the 'va_start' thing for me in more detail?  I don't
> really understand it.  And what does 'va' stand for?

 	"man va_start" :).  Sorry.  I've been assuming that you know C 
better than I do because you know more config-mgmt.  A few weeks ago, I 
wouldn't've recognised va_start either.  I'll ignore the rest of your 
reply in this section (above), and let you rephrase it in light of "man" 
(Sounds very 19th-century :) ).

>>>>  	Also, it might be nice to have a function in libmetric.c/h which
>>>> is something like get_result or something like that (get_metric_value?).
>>>> I suggest this because we might be able to alter things on the way through
>>>> if we so desire.
>>>
>>> Yeah, that is a good idea.  Should be pretty easy.
>
> So people could create filters?  I missed your statement about altering
> the output on the way out; how would we alter it?  That is, what exactly
> might we want to do to it?

 	Sorry.  If people call "get_metric(foobar)", we can eg. have it 
search the metrics first, and then search my variables afterwards, so 
that it can return something from either.  Or change the backend 
completely, and not have to worry about people calling it directly. 
Whatever :).

 	:)

-- 
Tim Nelson
Server Administrator
WebAlive Technologies Global
Level 1 Innovation Building, Digital Harbour
1010 LaTrobe Street
Docklands, Melbourne, 
Vic, 3008
Phone: +61 3 9934 0812
Fax: +61 3 9934 0899
E-mail: tim...@we...
http://www.webalive.biz/

"Your Business, Your Web, Your Control"