corona-admin web interface

[ryangrimm]

Given that configuring Corona is a rare activity, it would be nice to be able to easily configure things via a web interface on top of the JSON endpoints. Essentially providing a web interface to all of the /manage endpoints (at a minimum).

[eedeebee]

And give me a CLI please

[hunterhacker]

My first reaction was that something like this could be done in a client language to prove out the API, perhaps even by a third party, but unfortunately whatever language we choose isn't going to be very helpful to people who don't naturally have a server for that language. Example, don't give a .NET person a servlet-based admin interface. Too bad.

Personally, I think the CLI is lower priority. A web interface can be done once and is quickly usable by everyone. A CLI requires an install, configuration, and introduces platform dependencies. Maybe a web-based CLI could avoid some of that.

[ryangrimm]

For corona-admin users, why couldn't that client language be Javascript running in a browser? Why build out a middle layer to just speak to a browser? A middle layer is understandable at this point for users that aren't as privileged, but for the corona-admin user, the risk of direct browser interaction, to my eye, vanishes.

[hunterhacker]

OK, JS sounds good.

[eedeebee]

For admins, CLI is scriptable and more easily automatable - higher in priority in most admin lands imo. Can we make sure the js will work on the server too?

[ryangrimm]

In most cases I'd totally agree with you Eric (you know that I'm a pretty die hard command line user). But when thinking about scripting administration, I tend to think that the administrator has a set configuration that they need to apply to a machine. For this use case I think implementing the state serialization and reloading feature (RFE #32) is a easier way to go for everyone.

If an administrator needs to script something that falls outside of the state serialization they can always use the /manage endpoints. Perhaps not as convenient as a CLI, but it's one less layer to document, test and keep updated.

[hunterhacker]

Ryan said exactly what's in my head.

[eedeebee]

As long as the state serialization is higher priority than this, it makes sense.

Some notes from comment 3 above

• You can make a CLI take command line args (with good defaults) in place of/as well as configs so it could work o-o-box w/out config.
• CLI does have platform deps, but you could write a shell script that works o-o-box on os x, linux, cygwin that depends only on presence of curl.
• UI needs to be trivial else you'll have your own cross-platform issues wrt browser testing.