Ken McDonell wrote:
OK, I have a proposal for your consideration and feedback.
This is a bit long, apologies for that.
New pmimport proposal
Very nice; just a few points.
int pmiSetOption(int option, char *value)
Call this early on to set archive name (option == PMI_ARCHIVE),
archive's hostname (option == PMI_HOSTNAME), archive's timezone
(option == PMI_TIMEZONE), etc.
Why not have separate pmiSetArchive(), pmiSetHostname() et al?
int pmiAddMetric(char *name, pmID pmid, int type, pmInDom indom,
int sem, pmUnits units)
I know it's against the PCP tradition to be const correct, but could we
perhaps?
int pmiGetHdl(char *name, char *instance)
int pmiPutValueHdl(int handle, pmAtomValue *atom)
Good idea, but I don't see why you can't call these *Handle. Vowels are
cheap.
One other idea: if the timestamp argument to pmiWrite() is NULL, you
could internally substitute the result of gettimeofday().
I really like the PutValue{*}/Write design, this should definitely make
life easier for the filter writer. But what happens if you need to
parse a data file which you want to split into 2 or more PCP archives
(say because it contains data from multiple hosts interleaved) ?
Also, what's the defined behaviour w.r.t. threads?
For each of the routines above there would be a Perl wrapper
(pmiFooBar()
is wrapped by foo_bar()) and some constant functions and helper
routines,
so a Perl pmimport program might look like:
use PCP::IMPORT;
use vars qw( $import $myindom $inst $ctr $now $time );
$import = PCP::IMPORT->new('');
I don't see any point to having this object; if I understand the API
above it will have no state and just serves as a subroutine scoping
mechanism.
End of archive processing is needed to write the log trailer and is
handled by an atexit handler.
I'm not impressed by that. I think you'd be better off with an explicit
close function. I think that to be truly useful the API should be
capable of being used in a long-running program which writes multiple
archives concurrently or serially at it's whim.
--
Greg.
|