On 05/22/2014 07:14 PM, Nathan Scott wrote:
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?
I'm still not sure that this applies to our situation. In our case we
have an overall API (global options) and multiple "mechanisms" which
could each have their own options. Removing the global options from the
string is fine, but then each mechanism has to not only identify their
own local options, but also tolerate the local options of the other
mechanisms. This would presumably be done by ignoring them. We would
then have to make a final pass in order to diagnose the remaining
erroneous options. Seems a bit cumbersome, does it not?
The only advantage I can see to lumping all of the options into one
string is the chance that two or more mechanisms might share the same
option, but that can be covered by having a common function to handle
any common option.
Another way to simplify this might be to allow only one mechanisms at a
time. The main API (__pmDiscoverServices) currently loops serially over
multiple mechanisms, but perhaps this convenience is not necessary.
Dave
|