Full GUI

[calmcl1]

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]

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]

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]

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]

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]

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]

@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]

@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?