Split we.go into backends and frontends

[quite]

Suggestions: support http://openweathermap.org/api

[schachmat]

As far as I can see, they do not support ssl encryption. You should be aware, that any passive adversary inbetween you and the openweathermap server gets to know which locations weather you're interested in and can therefore probably conclude, where you live and where you're going to travel to in the next few days.

However, I already thought about splitting wego in backends and frontends. Each backend would then get the requested data from one specific API and convert it to a wego-specific format. Each frontend would take weather data in wego-specific format and reformat it for nice (current implementation) / parseable (just json?) / simple (a few lines of uncolored text?) / … output.

Patches are welcome, if you're interested, otherwise this backend/frontend separation will probably be done by myself sometime soon(tm).

[quite]

All right. Yeah, I see now that only paid plans offer SSL. I'm personally
don't bother to force ssl on weather and similar programs, but I understand
those who do.

[lacombar]

FWIW, this "open" weather map do not seem to be that "open".

[lacombar]

The wikipedia article about OWM talks about NOAA provided data. It might be interesting to check if NOAA provide SSL access to these data...

[lacombar]

Here is NOAA API informations: http://graphical.weather.gov/xml/ The site seems to answer on port 443, but the certificate domains doesn't match and the connection does not seem to make any progress.

[schachmat]

Some Ideas and plans:

• Each backend/frontend lives in it's own file inside the backends or frontends folder.
• Each backend/frontend registers itself against we.go within it's own init() function.
• The WWO backend should use objx instead of constant structs.
• The data structure interface should be roughly as the current structure but without structs. Use MSI with objx instead. Values should be supplied in metric format.
• Each backend/frontend should get it's own sub node in the config file (to setup API keys, language support, unit system, etc.)

I recommend extrating the backend first.

[schachmat]

I finally managed to implement a satisfying solution for config+flag management and split the backend. You can have a peek at it on the issue1 branch @a9c2c6f. The frontend split should now be straight-forward and done within the week.

[schachmat]

Finally done and merged into master.