Hi Dave,
----- Original Message -----
> [...]
> 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.
Thought of another possible approach over the weekend. If we expect this
interface to need further change (given this is the second version of the
interface now, with more development being planned in discovery, we should
plan for it) we could use a versioned interface like pmGetOptions(3) and
his little friend, pmdaGetOptions(3).
That might look something like...
typedef struct {
int version;
int interrupted; /* could become a flags bitfield? */
const char *globalOptions; /* and this could be more explicit, */
/* instead of every possibly option being */
/* coerced into one comma-separated string? */
} pmDiscoveryOptions;
int
pmDiscoverServicesWithOptions(
const char *service,
const char *mechanism,
pmDiscoveryOptions *options,
char ***urls);
That API looks fairly neat to me and is a bit more future proof than
what we currently have. As new extensions/requirements for the API
come along, using the version field & addition-to-end-of-struct-only
gives backwards compatibility almost for free (the libpcp code gets
to be simpler to extend internally too).
cheers.
--
Nathan
|