{"action":"created","issue":{"url":"https://api.github.com/repos/mitmproxy/mitmproxy/issues/1526","repository_url":"https://api.github.com/repos/mitmproxy/mitmproxy","labels_url":"https://api.github.com/repos/mitmproxy/mitmproxy/issues/1526/labels{/name}","comments_url":"https://api.github.com/repos/mitmproxy/mitmproxy/issues/1526/comments","events_url":"https://api.github.com/repos/mitmproxy/mitmproxy/issues/1526/events","html_url":"https://github.com/mitmproxy/mitmproxy/issues/1526","id":174911285,"number":1526,"title":"Mitmproxy CLI tools","user":{"login":"Kriechi","id":114300,"avatar_url":"https://avatars.githubusercontent.com/u/114300?v=3","gravatar_id":"","url":"https://api.github.com/users/Kriechi","html_url":"https://github.com/Kriechi","followers_url":"https://api.github.com/users/Kriechi/followers","following_url":"https://api.github.com/users/Kriechi/following{/other_user}","gists_url":"https://api.github.com/users/Kriechi/gists{/gist_id}","starred_url":"https://api.github.com/users/Kriechi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Kriechi/subscriptions","organizations_url":"https://api.github.com/users/Kriechi/orgs","repos_url":"https://api.github.com/users/Kriechi/repos","events_url":"https://api.github.com/users/Kriechi/events{/privacy}","received_events_url":"https://api.github.com/users/Kriechi/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2016-09-03T18:41:07Z","updated_at":"2016-09-04T22:52:24Z","closed_at":null,"body":"Similar to #1521, I'd like to open a discussion about the mitmproxy command line interface tools:\r\nAt the moment we have three core applications:\r\n  * `mitmproxy` - a curses-based terminal UI / \"frontend\" to inspect, manipulate HTTP flows, etc.\r\n  * `mitmdump` - basically only the proxy part of `mitmproxy`, without any interaction or \"frontend\"\r\n  * `mitmweb` - serves a similar use case as `mitmproxy`, but through a HTTP-JS \"frontend\"\r\n\r\nSince the main project is called `mitmproxy`, as well as the GitHub organisation, and the main repository, it was always a bit unintuitive how the actual binaries are called.\r\n\r\nTherefore I'd like to propose that we change the naming of the three main applications (i.e. the words we type into our terminal to start one of the three \"frontends\") to:\r\n  - `mitmproxy` - same as before, starts the curses-based UI\r\n  - `mitmproxy dump` behaves as the old *mitmdump*\r\n  - `mitmproxy web` behaves as the old *mitmweb*\r\n\r\nNow, in this case the first argument would determine the frontend to be started. By default (i.e. without a first argument) the curses-based frontend should be started. However, we could also change that, if we detect we are running without a tty (or the screen is too small) and simply fallback to *dump* mode. \r\n\r\nOr maybe instead of introducing a new argument, we could use `mitmproxy-dump` and `mitmproxy-web` as binary names. This probably requires one or two more keystrokes to autocomplete though.\r\n\r\nFor backward compatibility we should still ship the old binaries as well -and add a notification about the rename, so users can adapt their aliases / workflows / scripts.\r\n\r\nWhat do you think?\r\nI'm open for other naming conventions or even completely different names. 😄 \r\n\r\n/cc @mitmproxy/devs "},"comment":{"url":"https://api.github.com/repos/mitmproxy/mitmproxy/issues/comments/244633254","html_url":"https://github.com/mitmproxy/mitmproxy/issues/1526#issuecomment-244633254","issue_url":"https://api.github.com/repos/mitmproxy/mitmproxy/issues/1526","id":244633254,"user":{"login":"cortesi","id":22544,"avatar_url":"https://avatars.githubusercontent.com/u/22544?v=3","gravatar_id":"","url":"https://api.github.com/users/cortesi","html_url":"https://github.com/cortesi","followers_url":"https://api.github.com/users/cortesi/followers","following_url":"https://api.github.com/users/cortesi/following{/other_user}","gists_url":"https://api.github.com/users/cortesi/gists{/gist_id}","starred_url":"https://api.github.com/users/cortesi/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cortesi/subscriptions","organizations_url":"https://api.github.com/users/cortesi/orgs","repos_url":"https://api.github.com/users/cortesi/repos","events_url":"https://api.github.com/users/cortesi/events{/privacy}","received_events_url":"https://api.github.com/users/cortesi/received_events","type":"User","site_admin":false},"created_at":"2016-09-04T22:52:24Z","updated_at":"2016-09-04T22:52:24Z","body":"Let's think this through. Our options are: \r\n\r\n1. Keep the status quo: mitmproxy (console), mitmweb and mitmdump. Awkward, but reflects the reality that right now mitmproxy console is by a wide margin what most people use. \r\n2. Be logically consistent. Because console mode is not supported on some platforms, just having it as the default doesn't really work. This gives us \"mitmproxy console\", \"mitmproxy web\" and \"mitmproxy dump\". I don't like the guessing of looking at the tty to determine what to fire up, so I'd like to be explicit. So just running mitmproxy would list the tools and exit. \r\n3. Rename the mitmproxy binary to better reflect the fact that the project is not just about the terminal. All the options here are a bit ugly: \"mitmconsole\", \"mitmterm\"?\r\n4. mitmproxy-console, mitmproxy-web, mitmproxy-dump. I don't like this one. \r\n\r\n\r\nThere are a few other benefits I can think of for option 2:\r\n\r\n- Producing a single binary would cut distribution sizes by two thirds. Not certain how significant this is at the moment, but would be a nice side-effect. \r\n- This opens ops the possibility of adding more commands. For instance \"mitmproxy convert\" to convert from mitmdumps to other formats is something I've occasionally wanted. Very soon now, we're going to have the ability to upload mitmdumps for viewing online (I just need to clear time to work on this), so \"mitmproxy share\" might be another one.\r\n\r\nLet's wait for other folks to chip in on this, but tentatively I think the proposal makes sense. We can't make this sort of change often, though, so let's proceed cautiously. \r\n\r\n\r\n\r\n\r\n\r\n\r\n"}}
{"actor":{"display_login":"cortesi"}}