vadimdemedes / ronin

Toolkit for killer CLI applications
http://vdemedes.github.io/ronin
MIT License
299 stars 15 forks source link

Add shared history across machines #10

Closed pulkitsinghal closed 9 years ago

pulkitsinghal commented 9 years ago

Don't hate me!

I intend to help out with this feature request, I'm recording the motivation and problem statement here for feedback before I fork and start a PR. You may not see this as something that should be part of the Ronin framework so its best to get your feedback first and not waste any time.

First some PROs:

I often use Ronin when I don't want to build a website for solving problems when a cmd line tool will suffice.

  1. I imagine that most folks would want to avoid bearing the cost of hosting a public site for tooling they built.
  2. Asking consumers of your toolset to host their own website is a high-friction point and will probably cause a lot less folks to use it in the end.

    Now some CONs:

When the same CLI tool (developed with Ronin) is useful enough to be installed by users on multiple machines, some unique feedback crops up:

  1. Depending on the developer (me), the commands can get kind of long~ish and the only thing that autocompletes is the program name and not the commands. So I hear feedback about how that's a pain. So a shared history across machines (out-of-the-box for any Ronin-built program) would be quite a sweet feature. It would let any developer's audience leverage copy/paste from within the terminal like:

    $ my-ronin-program history
    1. my-ronin-program my-custome-command-name --myOptionA value --myOptionB value
    2. my-ronin-program my-custome-command-name --myOptionA value --myOptionB value
    ...
    9. my-ronin-program my-custome-command-name --myOptionA value --myOptionB value
  2. There may be scenarios where files (or some other artifacts) are spit out after crunching a task. Some of my users have compared this to a website and said: "Well with a CLI, I can't see my data across machines." Again there is a novel solution whereby linking to one's google drive or dropbox for any program built on top of Ronin could allow artifacts to be persisted and accessed across machines. Actually if the users have the respective google/dropbox agents already installed across their own machines, then all that's required is to point to the shared folder as the directory for reading/writing artifacts: $ my-ronin-program link-shared-folder ... as I finish writing this, I'm not so sure this particular bullet point is something that belongs in Ronin itself ... but I'll leave it here in case it sparks an idea on your side.
pulkitsinghal commented 9 years ago

So I couldn't figure out how or where the hello.js command is being spit out by code when user runs ronin new hello-world but if I understood that better I would basically just add one called history.js that would prompt the users to provide a path to any folder that is shared across their machines. Then save a history file in there that tracks the commands being run by the user.

vadimdemedes commented 9 years ago

Hm, I really really don't think it's a good idea.

  1. I don't use any actual use cases.
  2. The implementation of this will only complicate Ronin, which is not the point of the whole project.
  3. I feel that it is very very specific functionality and will not be useful to the majority of Ronin users.

If you definitely need this functionality for your program, you can either fork Ronin or implement it in your program directly.

pulkitsinghal commented 9 years ago

Thanks Vadim. Makes sense.