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.


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.

Attachment: signature.asc
Description: Digital signature

Reply via email to