Server: OSC to INFO proxy

[ronag]

Seems a lot of people are missing the deprecated INFO with xml response. If someone is up for it I would suggest implementing an OSC -> INFO http proxy in e.g. node. Similar to how we did the media scanner proxy.

[premultiply]

As INFO is basic functionality of any AMCP client-server connection I think it is not a good idea to deprecate it at all. Should be core functionality of AMCP communication as it is important for playout and automation. OSC is not a replacement for this as it uses a different communication channel and it requires other/additional parser etc. in client (if possible at all) and has other disadvanteges (data flow direction, firewall, serial link compatiblity, multi client usability, ...)

[dotarmin]

What I think @ronag means here is that we could simply route incoming AMCP INFO calls to an http request that pipes back the response to the caller without any difference from today, just as media-scanner proxy does for e.g. CLS, TLS etc. An advantage of this would the possibility to create multiple formats that are available and suits various needs of content and letting the proxy create the data for us.

@ronag am I right?

[ronag]

I was thinking of just making the OSC state available through http requests.

const state = {}
osc.subscribe(data => {
  state = data
})
http.get('/info', (req, res) => {
  res.send(getState(state, req.url)
})

It wouldn't take much for a fully functional implementation.

[TomKaltz]

Lets say you use a temporary layer with some random id. You then clear that layer but the last known state of that layer is still in memory. Doesn't this seems like a leak? There should be a way to clear or expire layer state.

[ronag]

@TomKaltz OSC always provides full state. Updated example.

[TomKaltz]

Ah so it will omit empty layers with this HTTP call. Got it.

[dotarmin]

I was thinking of just making the OSC state available through http requests.

But would the request be Client -> Server -> HTTP Request just as with media-scanner and then pipe back the response same way? Or are you thinking of Client -> node?

[ronag]

client -> node

[premultiply]

AMCP, OSC, HTTP, ... what's next? CIFS, SOAP, MQTT?
I do not like it. Would be the 3rd protocol to get only part of the required information and functionality on client side.

[ronag]

Well, yea... you can already get all the information through AMCP & OSC... so you don't need anything like this per se... I have nothing against re-adding AMCP INFO... if someone wants to do it and maintain it.

[ronag]

We use a [client <- websocket -> node <- AMCP/OSC -> caspar] proxy ourselves. So we can get and do everything over a simple websocket API.

[premultiply]

We use no proxy etc. and can do [client <- AMCP -> caspar] up to server 2.1. So we can get and do „everything“ over a simple TCP or serial line connection. Very easy to handle and configure for users. Only start the server and connect on port 5250. ;-)

[Punkley]

That is similar to what I do, as does Justmacros

My C skills are pretty lacking (php and perl is my language)

[TondaKrist]

I think that AMCP INFO is a must for simple playout automation and control. We really miss it... If it is possible, please, put it back to next builds...

[Punkley]

I second that.

[didikunz]

I also second bringing back the INFO commands, as they are much easier to use. And removing it breaks a lot of existing stuff. So please bring it back.

[elanvrt]

I concur with everyone who wants the INFO command back. OSC is great for frame-accurate timecode and audio levels, but it does not offer all the data that INFO has. And breaking backward compatibility with older clients is always a showstopper.

[Punkley]

We have a pretty high want for INFO to return, is there any chance it can happen?

So many tools that would need to be re-written

Kingsley

[dotarmin]

Info is coming back, discussion continue in #923.

Best regards,
Armin