Responders manager

[thomascullen]

trafficstars

We need a UI for users to download, install and configure responders without having to add and configure .js files. Similar to Atom's package manager.

[brock]

Along these lines, we might want to consider following the hubot model of "user scripts".

Hubot is a node app that is very similar to this project, in that it listens in a chat room (like Hipchat or Campfire) and responds whenever text matches a regex pattern that is defined in one of the scripts. This is nice because it prevents you @thomascullen from having to add each new script to the project, and it allows the user to add whatever scripts they want.

Hubot has gone through a lot of iterations since it started years ago, but the latest version, as far as I can tell, relies on a user installing a hubot script that is registered on npm. For a while they even maintained a hubot-scripts repo for any possible script, but even found that model to be too cumbersome.

In the end, the idea is that you simply encourage developers to create an NPM module that conforms to both a naming convention and an installation convention. And to expedite that process, I'd recommend we create a yeoman generator that has most of that boilerplate built into it already.

Here is what I'd envision:

Either of these:

• npm install --save voicebox-SOMETHING in the project
• add "voicebox-SOMETHING": "0.0.1" to a JSON file that we configure for scripts. Hubot uses a file called external-scripts.json as outlined here. There isn't an automated way around this, you just have to add it.

But to continue with this concept, voicebox-SOMETHING would be an NPM module based off of a boilerplate that does the following:

• Installs the script in the right location
• Possibly adds it to either package.json or some file like external-scripts.json

It prevents you from having to maintain all new scripts in this repo, and allows the user to pick and choose exactly what they want.

Another approach might be to save the external-scripts in something like ~/.voicebox. While I like this idea, and I think it would work for most people, the downside of that option is that you'd want to be able to make this directory configurable in the off-chance that someone was going to try to install this on a server and support multiple instances of Voicebox. While that may not be likely, making it a configurable option would allow you to work both ways:

Inside the project:

• ./external-scripts/voicebox-SOMETHING/...

Or perhaps on a web-server:

• /var/www/thomas/voicebox/external-scripts/voicebox-SOMETHING/...

Because on my local machine, this path would pickup all scripts, even if they were meant for multiple instances of Voicebox:

• ~/.voicebox

EDIT: just saw your comment related to this in the README. :+1:

[thomascullen]

Yes I think it would be nice for us to be able to pull in scripts from npm. However I would love to provide a UI for this rather than getting people to add it to a package.son file. The UI would have to work similar to Atom package manager. We could search npm for modules that begin with 'voicebox-' as you suggested, and then download them into a user responders folder. ( this would most likely be the appData path ). We would also need a way for responder scripts to have settings which can be configured in the voice box settings. Currently the way I have built the settings view is just using plain HTML and JS. I would like to move towards using React for this to have a more structured approach.

This is probably the biggest task to todo in voicebox. :)

[thomascullen]

Seems that it's not advised to use 'npm' programmatically. https://github.com/npm/npm#using-npm-programmatically

We could still spawn child processes to handle the downloads using npm though.

[loics2]

I tried a bit in my fork, but npm is actually a pain to deal with... And even if it's advised, even the atom package manager use the npm module instead of spawning child processes.

One good first step could be to externalize the responders (I started to do this in my fork, there's a responders folder at ~/.voicebox/<responder_name>) and defining the responders packages structure. The actual package downloading can come later, and in the meantime, the users could put the responders in the dedicated folder.

[thomascullen]

Yeah let's do that. I played around with creating the responders manager view yesterday and it seems that even searching npmjs.com can be a bit of a pain so I think externalizing them is a good place to start! I think we have two options here..

1. Something similar to what @brock suggested about having something like a responders.json which would be used to download modules from npm to a ~/.voicebox/responders directory.
2. Have a button in the settings window to open the ~/.voicebox/responders directory in finder to allow users to drag downloaded responders into the folder. This is similar to how Sketch app handles installing plugins.

One issue I can think of is how we are going to install responder dependencies so that developers can use npm modules in their responders.

We are also going to need to have someway to install a default set of responders when the app is first opened. This way we could extract each responder to its own repo.

[thomascullen]

I've made a very basic first pass at this on this branch. https://github.com/thomascullen/voicebox/tree/external_responders https://github.com/thomascullen/voicebox/blob/external_responders/app/responders_manager.js