Roku Developer Program

[roquoonewbie]

Is there any way at all to reply to an External Control Input Command with some type of response data?

For instance, if I use the "input" External Control Command to send a custom command of "GetVideoState", I am currently able to receive that command in my Brightscript (using an roInputEvent handler).

However, I see no way to reply back to the command so that the external calling application can get information back (like "State == Paused"). As of now, a successful command only returns a 200 OK response with a Content-Length of 0. Is there any way to instead pass back a (non-zero length) response body?

Short of creating my own http server using roStreamSocket, is there any way at all for an External Control application to send requests AND receive responses from Brightscript?

[gonzotek]

Nope. But depending on your application, it may be easier to implement a workaround by using rourltransfer to make http requests to the client. It could be something as simple as "http://client/response?state=paused". The client wouldn't necessarily need to implement a complete http server, just enough functionality to parse the raw data down to the url parameters; and to provide an appropriate response to any expected requests.

[roquoonewbie]

So, I either have to develop a custom server in the Brightscript app (using roStreamSocket), or I have to develop a server/listener in my external application, just so that the Brightscript can provide some simple response info to a command/call made by the external app?

Both of those options seem highly sub-optimal. Roku has already created a way for External apps to POST a simple HTTP command to Brightscript...can Roku comment on the possibility of extending this so that the handler in Brightscript can respond to that command with an arbitrary string returned in the HTTP 200 response sent back by Roku? Is this something being worked on or in a requested feature list?

[roquoonewbie]

Any word from Roku on this?

[RokuJoel]

I don't believe this is being developed at the present time. Shouldn't be too difficult for you to modify the webserver example in the SDK to support this though, not sure why that is sub-optimal, but it would involve some minimal effort to modify and then integrate the webserver code into your channel.

I'll pass your request on to engineering.

It isn't a bad idea, but it probably wouldn't be high on our priorities list unless a large scale business partner asks us to implement it.

However, our engineers do tinker a bit on their own from time to time, so you never know, cool things do show up. (In fact, several components like roScreen and roStreamSockets are the results of creative tinkering).

- Joel

[EnTerr]

I was quite interested and have mused over this over a year ago and figured Roku Inc has not added the feature because is technically challenging to implement with the way B/S message/event processing goes.
1. The web server will have to put the call on-hold and pass the parameters to B/S. But can that server handle concurrent requests? Likely will have to time-out at some point if no feedback from the channel.
2. B/S runtime will pass event to the program but when processing is complete, there is no way to return result back to the message loop. It would have to be call to some component perhaps?
3. To distinguish between different http requests, web server will have to slap some kind of (cookie-like) identifier to the input passed to B/S and expect it back when(if) response comes back, so it can match it back to a pending request.

Is there an easier way? If we in the forum can come up with simple enough idea, maybe they will implement it. So far seems PITA to me.