Rewrite jobs from Dashing to Kitto

[davejlong]

To build on Kitto's widget manager, we should add as many widgets/jobs as possible from Dashing's widget list to Kitto. The Kitto registry of widgets and jobs can be found on the wiki

[davejlong]

If you feel like your widget has enough general use to be in the core, create PR merging it into the installer template.

[JanStevens]

Maybe it will help if we can identify the widgets we want in core and create separate issues for them so people can easily contribute

[davejlong]

What if all widgets became gists? Then during mix kitto.new the "core" widgets is just a list of widgets that get pulled in automatically?

While I'm brainstorming:

What if all widgets were stored in a separate repository, similar to a Homebrew tap? It'd be easy enough to submit PRs to (for those of us that play the 24 Pull Requests game) and if you want to have your own repository of widgets privately, you could just pass a command line arg.

The CLI would look something like:

$ mix kitto.install comments
# Installs comments from a kittoframework core repo

$ mix kitto.install --repo davejlong/kittowidgets jira
# Installs the jira widget from davejlong/kittowidgets repo

[zorbash]

I'm positive on having a separate repo where anyone can submit a PR to contribute a dashboard, widget, job.

Pros

• More intuitive installation mix kitto.install comments. You just have to know the name.

Cons

• For the maintainer to keep the widget/job up to date she either has to be a collaborator on the repo or having to submit PRs on each change.

Concerning the core widgets, I don't think requiring an internet connection and depending on GitHub is a good idea since there's no great benefit.

[mackenza]

I am also in favour of the single repo per widget. This would make it very easy for others to contribute. The install from Gist thing was interesting but I don't think it's as friendly to testing your new widget and fixing issues as they are found.

zeit/hyper also does its plugins this way (to add on to prior art of Homebrew mentioned above).

[davejlong]

I was just looking at https://github.com/zeit/hyper. I noticed that they had setup a Kanban for plugin ideas. I'm not sure how GitHub's Project boards really work, but it would be good to have a spot to keep track of widget ideas that we'd like to see and the ability to mark them as wanting to see them in core or in Gists/Whatever the future of widget installation looks like.

[davejlong]

@mackenza also, it looks like https://github.com/zeit/hyper just uses NPM to share plugins. Unfortunately, I think Kitto won't be able to use any of the current package managers given the nature of jobs vs widgets. The question really comes down to do we follow Homebrew's style of repos that can contain multiple widgets and jobs and you can just install based on name or do we require devs to have an entire repo for a single widget or job?

[JanStevens]

Oke my two cents on this issue. First the widgets:

I think kitto should support CORE DISPLAY widgets and some example jobs. Basically what we currently have (maybe some more?). The only thing we should then allow in a sort of plugin system is the customization of jobs. These jobs would always (or most of the time) use the core display widgets (for example github job showing activity can easily reuse the graph widget). For displaying recent tweets we can do something like a list with image widget.

Having CORE display widgets makes it very easy to display data and the only thing that is custom are jobs. It would be possible to create your own widgets but if we provide a good set of defaults then this becomes not really that common. Now on the jobs:

What if we allow that any OTP application can broadcast changes to kitto/widgets? I think right now the job DSL creates a separate process that is supervised. If we would change the job to be a behaviour (genserver) its very easy to extend (and we don't need the DSL). The main purpose would be to make it easier to define custom jobs as an external OTP app that sends the right messages (so you can package it up in hex, define it in your supervisor tree).

Having the jobs in a separate OTP app makes kitto very lightweight and keeps the dependencies separate. For the widgets we would only need core display widgets (every mix job package can then specify they are compatible with for example the list picture or graph).

[mackenza]

I agree with the premise that solid core widgets that can take on the display of a type of data (i.e. lists, graphs, texts, images) is important. I am not super familiar with Dashing (not at all a Ruby/Rails guy) but some of the custom widgets seem very useless to me... like displaying the weather for a specific city. IMO the widgets should be generic (but configurable) and it's the jobs which you derive the data. I still think it useful to support custom widgets developed by the community. @davejlong If the widgets are not coupled to the jobs, then this is more about distributing front end stuff and maybe something like NPM is ideally suited for that?

As for the jobs, I am going to defer to you smart folks on that. I am fairly new to Elixir and don't grasp the proposed architecture you are proposing @JanStevens . I just want to make sure that the data we can surface in Kitto is not limited to jobs that require a deep knowledge of Elixir/OTP as much of what a user would need for this use case is remote APIs (GitHub, Twitter, Jira, PagerDuty, etc. etc.).

Perhaps this issue should be split into 2 or 3 new ones - 1 for evolving the core widgets, 1 for evolving the jobs, and 1 for community widgets?