search

hcr923fm / chronicle

An audio logger for radio stations
http://calmcl1.github.io/chronicle
Other
18 stars 1 forks source link

Full GUI #17

Open calmcl1 opened 7 years ago

calmcl1 commented 7 years ago

Configuring chronicle is all well and good, but it would be nice to have a full UI of some variety, to allow for a more user-friendly configuration experience, and to perhaps be able to access some more data - maybe even generated files via a web UI?

calmcl1 commented 7 years ago

I like the idea of a full UI, but in keeping with the single-responsibility idea (see #11) and to reduce bloat in the software, this will probably be manifested in another, separate project - just a UI for chronicle.

OliverWilkinson commented 7 years ago

Would it perhaps be worth thinking about a control API for this - facilitating creation of interfaces that can be built separately? (Eg a web admin page) which could then exist as separate projects? :)

calmcl1 commented 7 years ago

Absolutely! That was half-what I was planning. There was always going to need to be a structured control-set for in order for inter-process communication, but I hadn't really thought beyond an interface just for Chronicle. As you say, though, having a properly structured control API does make sense so anybody could take advantage of it...

mtunstill commented 7 years ago

I'm planning on using this for Wandsworth Radio (to replace PlayIt's recorder - pretty unstable on older hardware). Although a UI would be nice, APIs would be more beneficially to create other scripts to ensure all recorded output is there and feed certain files into show folders (keeping the raw logs separate).

I'd be happy to help style a UI if this takes off.

calmcl1 commented 7 years ago

Indeed, any form of GUI beyond the simple ncurses UI is going to require Chronicle to have a form of control API so as to be able to get and set Chronicle data externally.

What do you think would be the most useful? A REST style API, simple string passing on a given TCP port, named pipes? Personally, I'd lean towards a REST-style API, simply because it's more syntactically pleasant, can withstand version changes fairly easily and doesn't require any hard work or non-standard libraries for client apps to use.

Would a structure like GET http://<server:port>/v1/stream/0/start_time make sense?

mtunstill commented 7 years ago

@calmcl1: A REST-style API would be a good step. Could we elevate the HTTP methods to split out different functions as well to avoid accidental calls to API calls. Especially if you start to adjust settings, manually delete/transfer logs etc.

GET - Retrieve info. POST - Submit config and parameters to different settings. PUT - Upload a whole config to a running chronicle service (JSON/YAML format?). DELETE - Remove logs, remove config.

One good place to check out examples is Elasticsearch documentation (https://www.elastic.co/guide/en/elasticsearch/reference/current/docs.html) on how they implement theirs.

calmcl1 commented 7 years ago

@mtunstill Makes sense. One thing to work on is how each set of settings (?) might be named and accessed i.e. how do we structure the interface?