On Fri, Jan 13, 2017 at 09:22:01AM -0500, Thompson, David wrote: I'm seeing a trend where people write services with configuration types that don't cover nearly the amount of configuration options to make the service useful. MySQL, and now this Redis server, are examples of this. There are many more configuration options in Redis than this service exposes.
Probably what the author of the service does, it to provide just enough configurations to make it useful to him/her. In the kerberos service I took the opposite approach, and provided the full range of options that the underlying daemon has - the trouble is, I have only a very vague idea of what many of those options do - so I have no chance of writing a test which exercises them. What is the worst evil - having a service with limited capabilities, or having a service which is oestensibly fully featured, but we don't know if all those features work or not? I don't know the answer to that question. What do we do? File a bug with an example of how it could usefully be extended? Perhaps one thing we should do is - if we know that the service does not expose a particular feature, then we should ensure that limitation is explicitly noted in the manual. J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.
Description: Digital signature