Hi Dave,
----- Original Message -----
> On 05/22/2014 09:53 AM, Frank Ch. Eigler wrote:
> >> Hmm, above suggests we should've thought of an "options" parameter
> >> to pmDiscoverServices(3). [...]
> > One benefit of keeping options textual and similar is for their direct
Oh yes, "options" would definitely remain a char* comma-separated
string, as nature intended. :)
Point was, its a distinct thing to the mechanism, so the API is not
clean by combining the two. A bit like mount(2) options and the fs
type ... both of which are char* in the Linux syscall API.
> It makes it easy to extend the
> API without changing the ABI. Some options would be global, like the
> proposed timeout while others would be mechanism-specific, like the
> currently proposed maxThreads for active probing (although this could
> conceivably also be a global option).
> I like the idea of the mechanism-specific options remaining with the
> mechanism string. I would not object to an additional global options
> string. I had thought about it but thought that it was too late to add it.
There is a way to have our cake and eat it too - I have come across
option parsing APIs that behave as follows:
- comma-separated options string comes in across the interface;
- high level code does an initial pass over it, picking out global
options & adding those to global structures (__pmServerPresence
and/or __pmServiceInfo in our case, I guess);
- any global options found are overwritten with commas (heh!)
- the (still valid, but now without globals) options string is then
passed through to lower level code, which deals with the remaining
options.
How about we do something like that? We need to think about adding
that callback API (and the existing "get everything" could possibly
be a special case of that new API, for back-compat - not sure), but
now does seem a good time to make any additions (before introducing
an overloaded "mechanism" parameter).
cheers.
--
Nathan
|