This will now allow the mappings between services and channels to be created.
Some basic options have been created for the purpose of allowing certain
level of control of how the mapping is done.
The API code has also been updated to use the htsmsg auto conversion of
strings to map/list where required. Basic approach is check for list/map
first and if that fails fallback to string (if that's whats appropriate
for a mixed type field).
This is done on request if the string can be JSON deserialized. This is
useful for the common API where the webui will be sending in serialized
strings and saves having the special case "args" field.
For things like HTSP, which deal directly in htsmsg, the fields should
already have been converted to the right formats etc...
Really this lot could do with a proper tidy up, but probably for another day
and since this code is kinda shared with showtime I want to keep the changes
to a minimum until I've had a chance to discuss with Andreas.
The idea is that this will become a common API framework for both HTTP
and HTSP. And anything else we might think off.
The only real constraint at the moment is both assume a JSON like input
format (for simplicity) since they currently have that in common.
this is conditional based on a test run from the configure script, as this
type of test is certainly not 100% cross platform compatible.
However its very useful to have a true check of lock ownership rather than
the rather arbitary check that "someone" holds the lock.
This can now be disabled via tick-box at bottom of the grid and no data
is actually sent in the update, just which nodes have been updated.
There is still an inefficiency in that a bunch of nodes being updated could
result in loads of reloads, but that could be improved with a bit of client
side buffering/delay.
I still think too much data is sent in many instances. Often the same
info is sent over and over (particulary where the number of mux/svc per
network/mux increase).
