Drasko DRASKOVIC

I am not sure that we need this one. Config files are more difficult to distribute (although not much more), and we have nice solution no with [.env](https://github.com/mainflux/mainflux/blob/master/.env). @nmarcetic @anovakovic01...

Also - if we leave both solutions - ENV and `.config` files if present (or used with a `--config` switch), this might be the best option.

@chombium my opinion is that config via ENV variables is the best approach, but it would not bother me if config files and command line switches exist as an alternative....

@mteodor can you please give links to `nc.ChanSubscribe` and `SubscribeSync/NextMsg` and explain better the concept and what do you want to achieve here. We are not using Go channels here,...

These functions are using Go buffered channels, right? This might be possible, because our Writers are all written in Go. However, I would like here that we consider using NATS...

Also, this PR should cover user entity updates - like changing of the password.

@willcharlton this makes sense. However, I am afraid how this can't be resolved without groups (admins), and also - how `things` or `channels` can exists without an owner. @nmarcetic @chombium...

We need an external API to configure commands remotely. Also I expect this to hold some Mainflux-specific info (for example - on the gateway it has to interface with NATS...

It is a Mainflux command scheduler, not a Cron replacement.

The analysis showed good fit, with open question of scalability of Kuiper. We decided to proceed with integration. @darkodraskovic is working on this, and there is already draft PR opened:...