----- Original Message -----
> 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?
Heh, indeed. I was thinking more of the case like "timeout" where we
could implement this independently to any of the mechanisms, and which
would apply to all mechanisms.
But yeah, as soon as we go for a mode of passing all options to all of
the mechanisms, it falls down.
> 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.
Yep. That way, however, every mechanism has to know about every global
option, so whenever a new one comes along, the mechanism-specific code
for each mechanism would need to be updated (incl data structures and so
on). *shrug* ... perhaps there wont be many mechanisms though, and this
might be a non-issue.
> 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.
Right. Or, mechanisms could just silently ignore options they don't
know anything about - wouldn't need any sneaky-comma-overwriting then,
but clarity in error handling would probably be reduced.
Anyway, all food for thought - not clear there is one stand-out best/ideal
way to go here.
cheers.
--
Nathan
|