On 1/24/2012 5:28 PM, Russ Allbery wrote: > Andrew Deason <[email protected]> writes: >> Russ Allbery <[email protected]> wrote: > >>> Runtime configuration is usually the worst of all available options. > >> "Usually" depends on how narrowly you're defining this situation. For >> scenarios where the current behavior is known to be faulty but must be >> retained for behavior with unknown extant legacy software, I often find >> runtime configuration to be the only avenue for improvement. The >> alternative is to forever restrict functionality to maintain >> compatibility with clients that a site may not care about. (er, or the >> other alternative is 'breaking' backwards compatibility, but I don't >> really consider that an option) > > Runtime configuration is useful in this case for a migration plan, and > then should be removed in a later version in which the new behavior is the > only available option. But it still sucks.
Runtime configuration is not an option in this case because the behavior of whether or not a callback is broken in response to an RPC is part of semantics of the RPC. The way you change the semantics of an RPC is by implementing a new RPC. It is by implementing a new RPC that the client and server are able to agree upon the semantics. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
