On Wed, 2010-05-05 at 20:09 +1000, Max Matveev wrote:
> On Wed, 05 May 2010 07:39:30 +1000, Ken McDonell wrote:
>
> kenj> I'm suggesting that we remove all the asynchronous PMAPI extensions
> from
> kenj> libpcp as part of a PCP 4.0 goal.
> This is a provocation, nay, this is a casus belli, or maybe just a
> Wednesday with its bugs.
"justification for acts of war" seems a little harsh Max ... no missiles
fired so far and no children or animlals were harmed in the composition
of my original email ... 8^)>
> kenj> 2. the routines are not used by pmchart
> Which is probably a fault of pmchart, neh?
No ... if one separates the UI event-driven goo from the sync PCP glop
things tend to "just work".
> kenj> 3. the implementation is incomplete ... man pages exist for at least
> the
> kenj> following but there is no code in libpcp to implement these functions:
> kenj> pmRequestStore, pmRequestNamesOfChildren (oddly,
> kenj> pmReceiveNamesOfChildren is in the library!), pmRequestNameAll,
> kenj> pmReceiveStore and pmReceiveNameAll.
> pmRequestNamesOfChildren is in the library too but misspelt slightly.
OK, I'll bet I can fix the dislexic spelling mistaken in a commit
s/pmRequestNamesOfChildern/pmRequestNamesOfChildren/ and no one will
notice ... which is sort of the justification for my original position
(which I am no longer advocating, by the way).
> ...
> kenj> 5. there is zero QA coverage for the asynchronous routines (I was
> kenj> recently doing some gcov analysis in pmns.c which brings this issue
> into
> kenj> stark relief and triggered this mail).
> pmns side was the most troublesome (worse then connection
> establishment) to split into request/response parts, every other
> synchronous API routine was re-written to use two parts of async
> routines and as such should be well covered by PCP QA.
OK, we'll test that hypothesis if/when I broaden the gcov net during QA.
> So, what's the real issue? Lack of QA coverage or code bloat?
I have a philosophical objection to bloat ... so if we're including code
that no one is using it should be removed ... in this case it seems that
there are some pockets of use outside the open source PCP code so the
precondition is not met.
But if we're going to keep the code then having no QA coverage is a very
large risk. The recent derived metrics and dynamic metrics in the PMNS
involved lobotomizing big chunks of pmns.c, and if the async stuff still
works or works at all with derived and dynamic metrics that will be good
luck rather than good management.
So if the code is going to stay, I suggest it is up to those who are
dependent on the async routines to pitch in and offer some assistance to
expand the QA coverage (at least from a selfish point of view for the
parts of the functionality they care about or depend upon).
Cheers.
|