Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider --bind rather than --port/--address #16

Open
Nemo157 opened this issue Aug 7, 2018 · 4 comments
Open

Consider --bind rather than --port/--address #16

Nemo157 opened this issue Aug 7, 2018 · 4 comments

Comments

@Nemo157
Copy link

Nemo157 commented Aug 7, 2018

I realise I'm going against a lot of prior server CLI design, but I much prefer a more descriptive command line argument than the normal --port argument. A design that I've used in the past is

BIND_ADDRESS=127.0.0.1:5476
--bind 127.0.0.1:5476

which can reuse SocketAddr::from_str for parsing.

@spacekookie
Copy link

We could just add --bind so that people can choose...

@yoshuawuyts
Copy link
Collaborator

@spacekookie I don't like the idea of duplicating functionality in what's considered a limited space (e.g. there's a thing like too many flags). Instead I think it might be better to create a separate module called clap-bind-flag, which exposes similar-but-different functionality than clap-port-flag.

@Nemo157
Copy link
Author

Nemo157 commented Aug 8, 2018

@yoshuawuyts TBH that's how I was reading @spacekookie's suggestion (although I was thinking in the same crate). That way it's up to the developer of the service to choose how they want to present it to their users.

@spacekookie
Copy link

spacekookie commented Aug 8, 2018

I originally had a feature flag in mind, but creating a clap-bind-flag crate that uses common functionality from this crate is probably better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants