Roku Developer Program

[sjb64]

In the case we have a channel update, which of course has to go through Roku approval, and is released once approved, what if that update involves a schema change in our backend database web services? We cant make the change early, we cant make the change the exactly moment the new channel goes live, and we have to coordinate it with our other devices (website, phones, internal CMS and housekeeping, etc.) that use the web services.

My assumption is that we need to make sure the web services handle either versioning, device specific calls, or fielding in such a way that additional fields are just treated as extraneous, and old fields are left in place and ignored as needed (for example using positional fielding). None of these are a problem, we actually use forms of versioning and positional fielding now.

But before going with my assumption here, figured I'd ask if there was an official stance, or what others (I can only guess TheEndless has run into this) have done to deal with this, or if they're been bitten by this in the past.

[TheEndless]

I've run into this a number of times. Usually we end up either adding a version parameter to the API calls, or we move the API endpoint altogether and leave the legacy API endpoint up for a few weeks after publishing. Another option would be to build update detection into the channel, so the channel checks at launch and let's the user know if they need to update the channel manually or not.

[sjb64]

Yeah, Since the Roku data is pretty static (other than user data), I have my web services do data dumps onto a single serialized agrregate data file every 15 minutes, along with associated serialized detail files on movies (cast, etc) that the Roku reads via simple http and deserializes. The dumps are strored in a directory named by schema version (like 20150503), and the Roku (and other devices) grab the schema level they are looking for. Once the web services move on to a new schema, the old dumps just stay, and any unupdated devices pull they revision they want. Is a simple kludge and what I mean by 'forms of versioning', but it could be better, ideally when the Roku calls the web service stat function which gives current schema number (a call that is fixed in its format - schema, server datetime, a session hash key, etc.), I could force a Roku channel update even if its midday, but I don't think such an option exists. Am just looking for any thoughts of better ways or ideas, and as always I greatly appreciate your input.

[EnTerr]

RokuCo cannot solve for you the issue you describe. Even if they gave you a switch which *instantly* switches from version A to version B of your channel, so you can sync with your server-side switch (and here i am talking about magic elves, because nothing is instant in the cloud) - that still won't do, because Roku players will be checking for updates asynchronously for updates during a day or 2 or 10. Actually, someone may have the player disconnected for couple of months, then plug it and go right away for your old content. That's in your backyard - you should be prepared for that and not RokuCo.

On another note, seems to me you are over-designing your data exchange formats. Changing schemas, multiple deliverables, whaaat?
How about a K-I-S-S; if you get your format in such a way that the new incremental versions are compatible with the old clients?
So generally speaking, only the newest format is served and all - past and present - clients can consume it (the old ones understand only the parts they know). How is such magic possible? Easy. Say if your data dump is to CSV, then don't remove or change the order of existing columns, just add new ones. If you are using JSON or YAML, don't remove dictionary keys, can only add new ones if needed. And so on.

PS. The update curve is very steep but also has a very long tail. Over three years ago, when answering "What's the adoption rate for iPhone app updates?" question, i charted my data at the time i got good fit with this formula %updated = 25% + 7.5% * ln(#days). So a day after update went live i saw 25% downloaded it, 30% in 2 days, 40% in a week, 50% in a month. I think the curve is much steeper now and most people just hit "Update All", though i haven't looked at recent data. Yet, i released IOS update end of February, there was a big spike of updates that tapered within a week or two - but even today (i just looked) the number of updates daily is higher than the number of new installs/day. I guess what i am saying is, be ready to support legacy COBOL/CICS applications

[sjb64]

I knew Roku couldn't solve this, was more curious about what other people have done.

As far as the overengineering, the Roku is one part of a much bigger puzzle here, and, much like my dev setup (http://forums.roku.com/viewtopic.php?f=34&t=86102) seems excessive, it makes much more sense when you take into account some of the other things we have going on. The column idea you described I already do, just in a binary serialization format - without embedded field names like JSON or XML, I use positional fielding, but the end result is the same.

The Roku update thought was just wishful thinking, that I could pull a single web service call to my system, realize the Roku was out of date due to a versioning discrepancy, and trigger an channel update right there and then. Seems like it would be a simple thing for them to do as the Roku is perfectly capable of a midday update (system menu). Either a channel update or a full update, if that's the only way, would have prevented this from even being a question. So wasn't really "instant", so much as an on demand way to do something that would happen on it's own anyway.

The whole idea maybe is possible with ECP, but it isn't important enough to bother, and the menu structure isn't guaranteed to be stable in future updates (Home, Up, Right, Up...).

btw - CICS lol, next we'll have to support VMS, SSP, and 1401 Autocoder. You just dated yourself even knowing the acronym CICS existed.

[EnTerr]

"sjb64" wrote:
The Roku update thought was just wishful thinking, that I could pull a single web service call to my system, realize the Roku was out of date due to a versioning discrepancy, and trigger an channel update right there and then.

That leads to a pretty awful UX, if you think about it. Reminds me of most "smart" TVs - you want to run one of the streaming apps? Oh but you MUST upgrade the software first, we had disavowed all our previous work! When over-generalizing, i call this the "Android" approach (make developer's life easier) vs "iOS" one (make user experience better). In most such cases - whether intentionally or unintentionally - Roku has been taking the "high road", i think.

Seems like it would be a simple thing for them to do as the Roku is perfectly capable of a midday update (system menu). Either a channel update or a full update, if that's the only way, would have prevented this from even being a question. So wasn't really "instant", so much as an on demand way to do something that would happen on it's own anyway.

Ah, but there is bigger picture at play here too. The Co. does staggered software releases, as experienced by those reading about the "latest & greatest" features on their blog and then trying to force update just to see that nothing happens... for a week of eager-beavering. They do it waves based on player S/N, i think for two reasons: a) to smooth load on the servers and b) if SNAFU gets discovered in the wild (known to happen), as damage control measure they can stop further spread till firmware is fixed.

btw - CICS lol, next we'll have to support VMS, SSP, and 1401 Autocoder. You just dated yourself even knowing the acronym CICS existed.

Perhaps, to a degree. I have been involved in couple of project dealing with such acronyms though LU6.2 never grew on me and i had to google the latter two you mentioned. One was last century, the company was building a universal/unifying OLTP gateway and there was a tool that'd deal with legacy data exchange formats - as part of this i learned really well the DATA DIVISION of a COBOL program (wrote parser for it etc) and then we'd generate serialization/externalization code for C++/Java/VB/etc. The second was less than ten years ago and was about porting the prison/corrections system of one of the states from IMS to something more... this century. My point being, old code comes the haunt you once in a while. Like they say "Old fishermen (chemists, hippies, CICS/IMS etc) never die - they just smell that way"

[TheEndless]

"EnTerr" wrote:

Seems like it would be a simple thing for them to do as the Roku is perfectly capable of a midday update (system menu). Either a channel update or a full update, if that's the only way, would have prevented this from even being a question. So wasn't really "instant", so much as an on demand way to do something that would happen on it's own anyway.

Ah, but there is bigger picture at play here too. The Co. does staggered software releases, as experienced by those reading about the "latest & greatest" features on their blog and then trying to force update just to see that nothing happens... for a week of eager-beavering. They do it waves based on player S/N, i think for two reasons: a) to smooth load on the servers and b) if SNAFU gets discovered in the wild (known to happen), as damage control measure they can stop further spread till firmware is fixed.

There is an ECP command you can send to the box to force it to check for and install channel updates, but it won't update the currently running channel (for obvious reasons). My Update My Channels channel updates channels this way.

[sjb64]

That all makes sense, but I didn't know they implemented rolling updates, which again makes sense. Was just a thought on an edge case that I figured I'd throw out to get others take on it.

Enterr, not many people would have heard of SSP (IBM System/34 OS) or 1401 Autocoder, joys of having been in the industry for way too long 🙂