Yeah… Like most things I do, I design by building and modifying. I don’t usually sit down and work out the details, then implement. I implement on the fly. The biggest thing will be the opcodes used between *link and DMRmonitor… at some point, need to standardize a set that can inform DMRmonitor what kinds of tables to build/populate, etc.

Well, that and the fact that I know NO javascript…. 

Some things for the group that I feel really strongly about and hope to keep everyone on board with:

Continue using a python-based web server for it — maybe a different, more robust module — but I just hate making folks have to run apache, or nginx behind it… and an sql server, etc. I’d like to keep this so folks only have to know how to run one program to make it work.

The other is I *REALLY* want to keep it web socket based and avoid trying to support a gaggle of persistent http hacks (i.e. long polling). Why? I’ll explain by example: At the day job, we implemented IPv6 with full feature set parity back in 2003 (no shit)… because it’s the right thing to do, and someone needs to push forward instead of keep using a “it’ll-get-us-by” hack.

Goals for DMRmonitor on the IPSC side include using the same messages sent as log messages to update fields in the main DMRlink table in real-time about transmissions, etc…. and also to use RCM messages to show what each repeater is actually reporting that it’s doing — not just lighting it up red b/c it *should* be transmitting (a la c-Bridge). There are some really important reasons for this — I’ll give one example.

If you’re talking on a repeater and key up during BSID, you get bonked. If you’re talking away and when you let up the repeater sends a BSID, the channel is blocked. But the very nature of a call router isn’t going to “back block” that call through the entire network… So, you let up, the repeater goes into BSID, confbridge.py sends the other guy’s transmission back to you, consisting only of a short transmission like “See you at breakfast” and you never hear it. Then you say… well, the network is broken. There’s packet loss… something’s wrong…. I’d really like to get RCM in the mix because a repeater WILL REPORT if and why it blocks a call. I am pretty sure I’ve had COUNTLESS reports of problems for situations like this over the years - and sometimes actually gone chasing a problem that didn’t exist.