Hi Dave,
----- Original Message -----
> On 06/26/2014 12:51 AM, Nathan Scott wrote:
> >> There is now a new expanded API, pmDiscoverServicesAdvanced(1) -- name
> >> is not set in stone should anyone be able to think of a better one. See
> > pmDiscoverServicesExtended(3)? (or Expanded?).
> Hmmm, not really all that different really. The reason I am unsure of
> Advanced/Extended/Expanded is that, if we were to need another variant
> down the road, we will have reached a bit of a dead end when it comes to
> naming it. Perhaps the name should describe the actual enhancement --
> pmDiscoverServicesWithOptions(3)? Perhaps this is all just bike-shedding.
Ayup, 'tis a near-perfect bike shed. If we think there's a good chance
we'll be changing it again, at this stage, we should not be exposing this
stuff at the PMAPI level yet. We could go for use of the ever-delightful
double-underscore routines? (and down the track, we can promote into the
PMAPI once clarity arrives and we are more sure of ourselves).
Or, the pmDiscoverServicesWithOptions name would be fine too, though it
misses out on the new "interrupted" component I guess ... your call, but
it would be disappointing to see a third PMAPI addition anytime soon.
Ratcheting up the developer-pain-level (for ourselves I mean) by starting
to document these APIs in the Programmers Guide too, might provide more
incentive to stabilise the API. ;)
> > Also, the whitespace police called and sent through the attached patch
> > (and make some persnickety comments about that new function in pmfind.c).
> Merged and pushed. Which function, BTW?
Heh, bit of an obscure reference - I meant setupSignals() - its GNU-style
and looks like it arrived from outer space, relative to the code around it
- was it cut+pasted from somewhere?
cheers.
--
Nathan
|