Roku Developer Program

[uarlive]

Hello,

I am developing a channel which uses our in house API to access content. In order to reduce load on the API would it be bad practice to store the JSON results in the Roku registry?

Thanks

[RokuChris]

If you don't need the data to persist between sessions, it would be better to store it in memory. Build a caching mechanism into the class you develop to communicate with your API.

Only write things to the registry that you need to persist between sessions. And remember that the registry is limited to 16k per developer key.

[uarlive]

Thanks. That helps a lot.

[EnTerr]

Caching to "tmp:/" file comes to mind. Does that not provide a mid-level between in-memory (too volatile) and registry (persistent)? Am i right guessing tmp gets flushed only on player reboot?

[uarlive]

@EnTerr. That is the approach we are going to take. From what I understand the tmp:/ area gets cleared when the channel is exited.

[RokuChris]

"uarlive" wrote:
@EnTerr. That is the approach we are going to take. From what I understand the tmp:/ area gets cleared when the channel is exited.

Correct. Data written to tmp:/ does not persist between sessions.

[EnTerr]

"RokuChris" wrote:
Correct. Data written to tmp:/ does not persist between sessions.

RokuChris, could you please clarify what is a "session", in your (or RokuCo?) parlance.
You used the word 3 times here but i am unclear what that means. I searched the dev wiki and the only related mention is "boot session" in http://sdkdocs.roku.com/display/sdkdoc/roRegistry

[RokuChris]

"EnTerr" wrote:

"RokuChris" wrote:
Correct. Data written to tmp:/ does not persist between sessions.

RokuChris, could you please clarify what is a "session", in your (or RokuCo?) parlance.
You used the word 3 times here and i am unclear what that means. I searched the dev wiki and the only vague related mention is "boot session" in http://sdkdocs.roku.com/display/sdkdoc/roRegistry

When I say session in the context of BRS development, it's the period of time from when a channel is launched until that channel exits. It's a somewhat nebulous CS term not specific to Roku, which is probably why the docs don't use it. http://en.wikipedia.org/wiki/Session_(computer_science)

[EnTerr]

"RokuChris" wrote:
When I say session in the context of BRS development, it's the period of time from when a channel is launched until that channel exits. It's a somewhat nebulous CS term not specific to Roku, which is probably why the docs don't use it. http://en.wikipedia.org/wiki/Session_(computer_science)

Per that definition, "session" is something different. Simplifying the language:

"Wikipedia" wrote:
In computer science, [...] a session is [...] a dialogue, a conversation or a meeting, between two or more communicating devices, or between a computer and user

The focus is on conversation-as-an-entity, compare "telnet session", "chat session", "http session", "login session".

What you meant seems to be process lifetime (where process=app/"channel" execution/run). And the author of roRegistry doc entry by "within a specific boot session" meant during a single life of the OS. I'll keep this in mind as company-specific lingo.

[EnTerr]

"RokuChris" wrote:
When I say session in the context of BRS development, it's the period of time from when a channel is launched until that channel exits. It's a somewhat nebulous CS term not specific to Roku, which is probably why the docs don't use it.

I think i got some enlightenment with what i learnt about screensavers. Let's see if this makes sense?

A "session" for BrS is the lifetime (life span, existence, can't put my finger on the right word) of the app execution sandbox (the secured runtime environment). Since sandboxing is done at dev-key signature level, a session is not exactly the same as a channel execution: a session could last past a single channel run.

Sounds like hair-splitting but there could be practical consequences. Like for example if there is overlap of different "threads" runs A and B (e.g. main() and RunScreenSaver()) of the same channel or even different channels under the same devkey aegis - then B can use something from A past A's (timely) demise. This probably stems from the way sandbox is implemented, e.g. being kept based on ref.count; may or may not be intentional but does not compromise security model.