On Mon, 2010-07-05 at 11:31 +1000, Greg Banks wrote:
> ...
> >> Why not have separate pmiSetArchive(), pmiSetHostname() et al?
OK. pmiSetArchive() has been replaced by pmiStart(char *archive) since
we now have a mandatory call to pmiStart() for each context (formerly
called streams) and this needs an archive basename that cannot be
defaulted.
The hostname and timezone will default to the local host, but can be
explicitly set after pmiStart() by calling pmiSetHostname() or
pmiSetTimezone().
[deleted discussion about streams/contexts]
> I think it would be a good idea to carefully define and document the
> semantics of calling pmiChangeStream() while partway through a sequence
> of pmiPutValue() calls, i.e. what happens to the partly constructed
> pmResult.
It is preserved ... the partial pmResult state is maintained per context
and kept until pmiWrite() is called.
Which leads me to another thought where we may have a disconnect ... I
was assuming the set of metrics and instance domains and instances was
private per context. I realize that this may not be what you're
expecting.
In my assumed model, to get the metric "foo.bar" into two output
archives would require.
one = pmiStart("one")
pmiAddMetric("foo.bar", ...)
pmiAddInstance(123, "mumble", 2)
pmiAddInstance(123, "fratz", 3)
two = pmiStart("two")
pmiAddMetric("foo.bar", ...)
pmiAddInstance(123, "mumble", 2)
pmiUse(one)
pmiAddValue("foo.bar", "mumble", ...)
pmiUse(two)
pmiAddValue("foo.bar", "mumble", ...)
It would just as simple in the implementation to make the metrics,
instance domains and instances global across _all_ contexts (so the
second batch of calls to pmAddMetric() and pmAddInstance() above would
not be needed). The only downside of doing this would be that _if_ one
ever wanted the same metric to have different metadata (including any
associated instance domain) for different output archives, then you'd
need to invent a new name for each output archive ... this seems pretty
unlikely.
If I make the metrics and indoms and instances global, then it makes
sense for the "handles" to be global too.
But I'd keep the partial pmResult data private per context.
Thoughts?
> ...
> >>> $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.
> >>
> >
> > There is a heap of state that has to be held across calls to
> > libpcp_import routines (metadata, partial pmResult, ...).
>
> Sure, but all that state is in the C library right?
Correct, so I'll just lose the object abstraction. I assume trimming
the pmi prefix off the routine names for the Perl wrapper routines is a
bad idea, as this leads to potential name clashes with names that are
not prefixed PCP::IMPORT::, e.g. Start(), End(), Write() etc. Is there
a convention to follow here? My initial though was pmiFooBar() ->
pmi_foo_bar() for the Perl wrapper, but I really don't care so if there
some preferred naming regime point me in the right direction and I'll
follow that.
|