Organising option flags

[raulk]

As users demand more functionalities (e.g. #34), we're likely to see a proliferation of option flags for the daemon binary. While the daemon is marked as an experimental project, we should attempt to bring in structure to our option flags. Let's agree on an approach and lock it in.

Proposal:

• Let's be idiomatic. I found that camelCasing flags is not really idiomatic in Go: go test uses no casing or separators, and ipfs uses hyphens. My proposal is to use hyphens.
• Let's namespace our flags.
• Let's strive for consistency. Consistency can look different in each namespace, e.g. for transports, we can make all flags additive (a flag adds support for a transport), and provide a single subtractive flag to disable OOTB defaults. The connection manager deals with values, so it'll look different.

For transports, this can look as follows:

-tpt-enable-quic        enables the QUIC transport
-tpt-enable-ws          enables the WebSockets transport
-tpt-enable-tcp         enables the TCP transport
-tpt-disable-defaults   disables the default transports 

So if I wanted to enable ONLY QUIC, I'd do the following:

p2pd -tpt-disable-defaults -tpt-enable-quic

WDYT? CC @vyzo @bigs @jrhea @cheatfate @mhchia

[cheatfate]

Its nice, but i think WebSockets transport could not work without TCP transport and QUIC transport could not work without UDP transport. Also from my early experiments there not so many nodes in network which support something different from TCP, So i think this options can be useful only when network will be able to satisfy it.

[vyzo]

This is nice for testing. We should also have a flag that specifies the listen addresses, so that we can only listen on QUIC for example but still be able to dial tcp.

[mhchia]

It's pretty nice to me. If there are too many combinations of the flags in a namespace, does it make sense to have something like -tpt="tcp,ws", and the argument parser handles the logic?

[jacobheun]

I like this approach, I think it would be great to get spec'd out. When implementing the js daemon I referenced the cli parser of the go implementation, but it would be great to see that externalized as a spec. This will also ensure our interop testing is a lot easier if we can just leverage the same flags consistently.

If there are too many combinations of the flags in a namespace, does it make sense to have something like -tpt="tcp,ws", and the argument parser handles the logic?

I'd like to see us leverage something like #63 to overcome the large number of flags problem. I think it's a nice approach for running more customized nodes.