Hi Dave,
----- Original Message -----
> [...]
> My current felling is that we should stick with the string arguments and
> the interrupt flag and call it pmDiscoverServices1(1). While it seems
> likely that new options will be added to the API, it seems less likely
> that they will require another argument to be added and so I don't
> expect that we will be an explosion of versions. It is also consistent
> with the strategy chosen (and retained in all versions) of parsing
> options in the mechanism string.
I got the impression earlier that you were expecting more parameters to
be needed down the track, and that strings would not be ideal...? (like
the "interrupted" parameter). If that's not the case and we can get
rid of that extra parameter, lets keep it simple and go back to strings
as you suggest.
That name is still really un-helpful though. :( Please use something,
anything, other than a number (inconsistent with the rest of the PMAPI
and it says to the API user "I could not find words to describe this
thing").
In fact, double-underscore prefix is looking a really good option here
given the lack of certainty - please seriously consider that - we can
always add the PMAPI-level symbol later, once we've had more time to
consider and see what else comes up.
So, pick one of the above two approaches please, and if not settled on
a direction you're happy with by weeks end, lets yank this code and try
again next release?
Thanks mate.
--
Nathan
|