Brainstorm

Ahh, get it out! Get it out of my head!

Clint

• Keep API Simple - One of the appeals of hain was the simplicity of its API, I think we should aim for that as well.
  • If we can keep the required API simple, yet allow for expanded optional functionality I think that would be even better.
• Keep the Core Tight - Like Heejin did with hain, much of the user-functionality was written as plugins (he ate his own API).
• Threading / Concurrency - I think the original design could be improved by threading and concurrency
• Sandboxing - We can sandbox tightly what plugins can do, but should we?
  • We could also offer a few 'permissions' that the user could grant that would allow plugins to do specific security related things (such as local file access, global hotkeys or some other such thing) - This just goes hand in hand with protecting users from aberrant plugins with too much power. (Maybe we shouldn't try to be the police, dunno)
• Cross Plugin Communication / API - I think there are some great possibilities for plugin authors to expand on 'services' for plugins. Think of it as an npm module for hain plugins. An example might be a plugin that just provides website favicon services to other plugins.

Brayden

• Resources and dependencies should be decentralized or built on solid frameworks, repos, etc. I am mainly looking at Hain's need to go through http://npmsearch.com (which is itself a dead project too). It really is a weak point for plugin distribution. It would make far more sense to have a more standardized method for package/plugin management rather than trying to roll our own. More to the point if we need to query npm find a more direct way to query than a proxy site.

• I do agree with the tight API scope. 'Eating our own API' might not be a bad idea. It will give us a good perspective on what plugin devs would have to sift through to get something running. It would also open up the possibility of a very modular launcher. Options are always nice :)

• I mentioned this in 'Research' but a more dynamic approach to command arguments/parameters would make user and developer experience much more flexible. Specifically, I am looking 'tab separated' commands found in launchers I have loved in the past (ie Launchy). Parsing Hain's arguments in one giant string was not fun.

• Might go without saying but a light minimal design would be awesome. This was a great aspect of Hain. Definitely, something we should emulate with this project.

Heejin

• Electron Applications needs too much memory footprints, so we need to carefully design every component to reduce memory footprints as much as possible

• We might need to make several layers for plugins (1st party: no sandbox, 3rd party: sandboxed), then we can reduce memory footprints as much as possible