search

marklogic-community / Corona

Community REST API for MarkLogic
Other
37 stars 9 forks source link

corona-admin web interface #68

Open ryangrimm opened 12 years ago

ryangrimm commented 12 years ago

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 commented 12 years ago

And give me a CLI please

hunterhacker commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

OK, JS sounds good.

eedeebee commented 12 years ago

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 commented 12 years ago

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 commented 12 years ago

Ryan said exactly what's in my head.

eedeebee commented 12 years ago

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

Some notes from comment 3 above