Mormon Channel Web Service Content

What is the current strategy for content retention on the Mormon Channel?

I'm in the process of doing some work on an app using the Mormon Channel Web Services (http://tech.lds.org/wiki/Mormon_Channel_Web_Services) and quickly realized that everything that is listed on lds.org is not available through the service.

I'd love to have access to the different formats (360p, 720p, and 1080p) available on lds.org as well as the archival videos. The web service only seems to have last two years of conference for video while lds.org has more... I was hoping to see that the web service would provide access to these without having to screen scrape (eh hem... http://tech.lds.org/wiki/Third-party_AP ... el_content).

Any clues as to what will be there and what won't? Or if there are any public api's to see what is on the lds.org CDN's? Since it looks like that's where they are storing their stuff...

Thanks!

tylerrussell wrote:I'm in the process of doing some work on an app using the Mormon Channel Web Services (http://tech.lds.org/wiki/Mormon_Channel_Web_Services)...

It doesn't sound like you are part of a team working on an official Community application, and you clearly aren't using the upcoming official third-party API. So you shouldn't be using those web services. See this post. When the public third-party API is released, then you will be able to access the content legally.

As for what content will be available, I don't know.

I didn't realize that the Mormon Channel Web Service was what they were referring to as an "internal" service. Seems weird that an internal service would be publicly documented and access granted globally if it's not supposed to be used. I thought there was some other internal service or something =p

Sounds like I'll have to talk to the necessary people to see if they deem my app "worthy" of becoming a community application or of using the official third-party api.

On a side note, the statement by Joel in the post you linked seems to be specifically directed towards web services using SSO or Lds Credentials to access sensitive information (ward calendars, directories, etc). I dont think the same policy apply (or if it does, should) to publicly available media contact (Anyone can go to lds.org or mormonchannel.org and view this stuff). Globally limiting web service access greatly hinders the "hobby" projects that a lot of niche areas thrive on.

In my case I'm writing Python script plugins for XBMC to access Mormon Channel content so people who use XBMC on non-pc devices lacking internet browsers (ie Apple TV, openElec distros, or other set top boxes). Yes, I know this is officially available through a Roku box, but why buy a Roku box when I can use open source XBMC?

Wasting a project manager's time with all of the necessary red tape for 4-5 python files is not on the top of my list of things to do. I'd much rather just develop it and then release the source publicly and let ICS pick it up if they deem it a worthy addition. But at least that way people can benefit from something that's out there. Even if it is marked as "unofficial" and not distributed through Church channels. Just my two cents.

tylerrussell wrote:I didn't realize that the Mormon Channel Web Service was what they were referring to as an "internal" service. Seems weird that an internal service would be publicly documented and access granted globally if it's not supposed to be used. I thought there was some other internal service or something.

Well, the introduction to the documentation says "As part of the Mormon Channel products..." -- that seems to make it pretty clear that it is intended for the Mormon Channel products. It's not so weird that it would be publicly documented when you consider that the app was developed largely by Community developers. Yes, access to the information could have been restricted to only the actual developers, but that would have been more complicated.

tylerrussell wrote:On a side note, the statement by Joel in the post you linked seems to be specifically directed towards web services using SSO or Lds Credentials to access sensitive information (ward calendars, directories, etc). I dont think the same policy apply (or if it does, should) to publicly available media contact.

You're right. My link to that post was misleading and does not apply to the Mormon Channel Web Service. Sorry about that.

tylerrussell wrote:Wasting a project manager's time with all of the necessary red tape for 4-5 python files is not on the top of my list of things to do. I'd much rather just develop it and then release the source publicly and let ICS pick it up if they deem it a worthy addition. But at least that way people can benefit from something that's out there. Even if it is marked as "unofficial" and not distributed through Church channels. Just my two cents.

The article you linked to ( Third-party API for gospel content) does say that the restriction on using any technique other than the upcoming public API will not be enforced until the end of Q1 2012. But it seems like it would be a better long-term approach for you to use the new API, rather than an internal API which you won't be able to use legally past March.

But it seems like it would be a better long-term approach for you to use the new API, rather than an internal API which you won't be able to use legally past March.

I agree. I wouldn't want to develop on the Mormon Channel Web Service and then have to switch the whole API later anyways.

I'll send in a request for access to the beta public API and move forward from there. Thanks for answering all my questions!

aebrown wrote:But it seems like it would be a better long-term approach for you to use the new API, rather than an internal API which you won't be able to use legally past March.

I agree. I wouldn't want to develop on the Mormon Channel Web Service and then have to switch the whole API later anyways.

I'll send in a request for access to the beta public API and move forward from there. Thanks for answering my questions and for the information on the different services.