pcp
[Top] [All Lists]

Re: pmServiceDiscoveryInterrupt() commit a8b87e2 et al.

To: "Frank Ch. Eigler" <fche@xxxxxxxxxx>, Nathan Scott <nathans@xxxxxxxxxx>
Subject: Re: pmServiceDiscoveryInterrupt() commit a8b87e2 et al.
From: Dave Brolley <brolley@xxxxxxxxxx>
Date: Wed, 09 Jul 2014 14:25:37 -0400
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <y0mpphe60bw.fsf@xxxxxxxx>
References: <20140619194444.3B03D58015@xxxxxxxx> <1063089485.33910956.1403758262805.JavaMail.zimbra@xxxxxxxxxx> <53AC35B8.3000802@xxxxxxxxxx> <1193390011.34470957.1403829231937.JavaMail.zimbra@xxxxxxxxxx> <1374649635.181830.1404090114319.JavaMail.zimbra@xxxxxxxxxx> <53BC0D60.4000007@xxxxxxxxxx> <y0md2df8vse.fsf@xxxxxxxx> <53BC5248.5050100@xxxxxxxxxx> <256416707.6217487.1404883930815.JavaMail.zimbra@xxxxxxxxxx> <y0mpphe60bw.fsf@xxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
OK, so I've got two well respected reviewers disagreeing on how to protect the service discovery API/ABI from future changes. Meanwhile the latest and most controversial version has been merged. At this point we have to come to a decision before the version du jour ends up in the next release.

One thing that all the versions have in common is string arguments specifying the service to be discovered and the mechanism(s) to be used. The latter, in every version, already features options appended to the string and separated by commas. There is the potential for this in the service string as well. This interface has the useful property that new options can be added without breaking API or ABI compatibility with older clients.

When the need arose for options global to the discovery process, my first attempt was to add a global options string argument. This also had the ABI/API-protecting quality that we're looking for. In order to add interruption capability, it was necessary to add another argument providing a pointer to a flag indicating that interruption had or had not been requested.

All seemed well at that point, and then I asked for input on the name of our new API function. A new function was needed because the previous API had already been released, although one could probably argue that we're currently the only ones using it. Using names descriptive of the added functionality seems problematic and unwieldy, however, attempting to version the API/ABI does not seem like much of an improvement over using strings at the cost of a lot of additional complexity and opportunity for error.

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.

My 2 cents,
Dave

<Prev in Thread] Current Thread [Next in Thread>