----- Original Message -----
> [...]
> > Also, the fg py binding might probably slot into the pmcc classes
> > better than pmapi, but then under the hood you've extended libpcp so
> > I guess it belongs in pmapi.py,
Yes, direct calls to libpcp via ctypes belong in pmapi.py.
> so we might be able to eventually
> > delete some of the pmcc helpers (?)
+1
> One could rework pmcc to use pmfg perhaps. Or leave it alone as a
> legacy API.
pmcc is not just a fetchgroup-alike API, it does a number of other very
useful things too, abstracting code out from high level python scripts.
These things are needed still and always will be (see -T pmrep bug from
earlier mail). We also would like to add config file support and other
higher-level API concepts into pmcc, so it (or something like it) is not
going away.
Updating pmcc to use pmfg should be useful on several levels - as you say,
Mark; it should cause a reduction of code in pcp.pmcc, and we need to have
a coherent plan going forward - otherwise we might see a last-minute series
of patches a couple of days before release, where folk try to second guess
the appropriate future API to use (*cough*).
So, we need to see a resolution to this - either as a "pmfg+pmcc" API or a
"pmfg+new-high-level-API" (if pmcc/pmfg cannot be tweaked to work together
& in that case, we need to see that new API, and understand why its needed
over pmcc) before any core libpcp fetchgroup addition is added - this lack
of cohesion is already causing confusion. There's plenty of time; hmmm,
except that we are keen to start abstracting a bunch of code from pmrep to
..somewhere (pmcc?) soon, so the sooner the better I guess.
+1 for pmfg event metric support too, BTW; other fetchgroup implementations
like libpcp_qmc support 'em - any API being added into libpcp itself should
certainly be complete.
cheers.
--
Nathan
|