Hi, Mark -
mgoodwin wrote:
> [...]
> Amazingly coincidental choice of names, check out :
> git://oss.sgi.com/markgw/pcp/pcp-new-open-source.git
> src/libpcp_mon/src/fetchgroup.[ch]
>
> which I wrote way back in 1995 (!) as part of the original pmchart - in
> response to exactly the same API wordiness issues that you've encountered.
Funny not-entirely-coincidence. Thanks for the pointer to the code.
>> Second, do you endorse the type-safe nature of passing float*
>> etc. destinations for the metric values [...]
>
> yes definitely, though you could take it further and canonicalize
> on just double (or even long double for better precision), string
> and aggregate (and event?).
Yeah, that would make sense (because representing moderate-sized
integers in float/doubles is lossless).
> [...]
>> Fourth, I don't know what to do with events. They're fiendishly
>> complicated in the pmValue structures, and would have a whale of a
>> time encoding its recursive subdivision as one function call. Maybe
>> skip it? Maybe some nasty varargs monstrosity?
>
> hmm, we didn't have that problem back in 1995 :) Just treat it in a
> similar way - copy the event into a user supplied buffer .. something
> like that, basically a special aggregate type.
It's not that easy though, since fields of an event tuple are N
individual atom values with distinct types/etc. I'm leaning to
punting for now.
> [...]
> there you go, and half the work's already done :)
Thanks, I'll study your code and steal lots of bits. I'm leaning
toward a little simpler solution in some ways. For example, how about
just use one pcp context per "fetch-group"? That would make it less
necessary to have special time-setting or profile-manipulation
wrappers, since it would compose with the normal PMAPI functions.
- FChE
|