Linked by Thom Holwerda on Wed 2nd Jan 2013 23:38 UTC
Microsoft Microsoft's legal chief: "We continue to be dogged by an issue we had hoped would be resolved by now: Google continues to prevent Microsoft from offering consumers a fully featured YouTube app for the Windows Phone." Utter nonsense, since MetroTube offers a complete and full YouTube experience on Windows Phone (it's one of the best Windows Phone applications), and YouTube+ on Windows 8. Two fantastically rich applications, built by small ISVs - yet Microsoft can't do the same? Don't make me laugh. Coincidentally, Microsoft is also whining some more about Google's removal of ActiveSync - Redmond again refuses to acknowledge that all it needs to do is implement the open standards CalDAV and CardDAV, just like everyone else has done. Times have changed, Ballmer. You don't get to dictate the industry anymore.
Thread beginning with comment 546941
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Please Thom
by Nelson on Thu 3rd Jan 2013 00:33 UTC in reply to "RE[5]: Please Thom"
Nelson
Member since:
2005-11-29


Proof buddy! You have none. If you do, please show it. Otherwise, this conspiracy of yours is bullshit.


So providing access to the API for iOS and Android clients but refusing to grant Microsoft permission to use said API, and refusing to grand MetroTube permission to use the API isn't a direct attack on third party YouTube apps?

I really struggle to understand your thought process sometimes.

Reply Parent Score: 6

RE[7]: Please Thom
by sec0ndshadow on Thu 3rd Jan 2013 14:36 in reply to "RE[6]: Please Thom"
sec0ndshadow Member since:
2013-01-03

A couple of things. Firstly, I don't understand what _you_ don't understand about the work "private" in "private API."

Second, I don't understand why, exactly, it is you think that they are in any way, shape or form obligated to provide the same level of access to 3rd parties to begin with...

Those iOS and Android apps? They were developed _by Google_ last I checked. Could it be, just maybe, that they don't see the _value_ in developing a Windows Phone version because it's just not a large enough market and viewed as a waste of time?

And maybe, just maybe, part of the reason that they don't have a fully featured public API is that they are still changing it and don't want to be tied to an API interface that would be sub-optimal? The fact that the private interface changes and breaks things is a bit of a hint...

They've been doing an awful lot with YouTube lately that seems to be in an effort to bring it in line with the rest of Google's product offerings and this may be part of that.

OR

Perhaps they don't have a "fully featured" public API because, well, they just don't want to.

Which brings us full circle back to using private APIs to build one. Well thats cool. Go ahead. But understand that if you use undocumented, private APIs to do anything they _can and will_ break. It's not necessarily trying to actively subvert 3rd party clients. It's a developer changing an internal API. Private APIs are subject to change at _any time_ without notice because they are PRIVATE. That's what PRIVATE API means.

Get. Over. It. There is not conspiracy. Some just did the equivalent of changing a function signature or move a class around.

There is no conspiracy. That's just how software development works.

Reply Parent Score: 2

RE[8]: Please Thom
by Nelson on Thu 3rd Jan 2013 16:25 in reply to "RE[7]: Please Thom"
Nelson Member since:
2005-11-29

A couple of things. Firstly, I don't understand what _you_ don't understand about the work "private" in "private API."


I'm quite aware, given that I've implemented an iteration of said private API in the past.

In fact, I even mention it as a reason why it is not possible for Microsoft to use. Because it is exactly that, private, and it would violate the Terms of Use that you agree to when using the public portion of the API.

I think you didn't really bother to read my posts. So again, please, read my posts before replying next time.


Second, I don't understand why, exactly, it is you think that they are in any way, shape or form obligated to provide the same level of access to 3rd parties to begin with...


I think we've really come full circle in these comments. The same people who so vehemently oppose proprietary protocols (even ones with documentation!) are suddenly in favor of a completely closed and undocumented protocol because it is made by a company they happen to life. That is the definition of a double standard.

I don't much care what Google does, they can restrict it all they want. I care when people try to paint their actions as noble or justify it with some sort of moral high ground.

Its an underhanded tactic, but some (Thom) would have you believe that everything is okay because some enterprising developers use undocumented APIs.


Those iOS and Android apps? They were developed _by Google_ last I checked. Could it be, just maybe, that they don't see the _value_ in developing a Windows Phone version because it's just not a large enough market and viewed as a waste of time?


And you're wrong. Google does not make the YouTube app on iOS (Or didn't until recently, it was done in-house by Apple).

If they don't want to do it, that's fine. But Google cutting off negotiations with Microsoft, when people inside YouTube's team wanted them to have this access is egregious.


And maybe, just maybe, part of the reason that they don't have a fully featured public API is that they are still changing it and don't want to be tied to an API interface that would be sub-optimal? The fact that the private interface changes and breaks things is a bit of a hint...


They can have their reasons for not having a fully accessible API, but at the very least, they should be willing to work with vendors of a reasonable size to enable support on other platforms. It's about interoperability.

Google is purposely locking Microsoft out, it is an executive decision to not supply Microsoft with the permission it needs to submit an app they have ready.


They've been doing an awful lot with YouTube lately that seems to be in an effort to bring it in line with the rest of Google's product offerings and this may be part of that.


Again, understandable. However its curious their 1st party apps don't seem to suffer from these routine outages. The back end changes don't functionally change the "shape" of the API, but add more detection to prevent the spoofing of requests which open it up in the first place.

Something you'd know if you ever tried to consume this API before, or spoke to the developers of popular third party apps.


Perhaps they don't have a "fully featured" public API because, well, they just don't want to.


Again, it'd be ideal if they did, but they are within their right not to. They don't have to let anyone do anything. But they don't get to claim some moral high ground when Microsoft complains, and it certainly is not fair of Thom to say that its Microsoft's fault they can't engineer an app because Microsoft refuses to use private APIs.


Which brings us full circle back to using private APIs to build one. Well thats cool. Go ahead. But understand that if you use undocumented, private APIs to do anything they _can and will_ break. It's not necessarily trying to actively subvert 3rd party clients. It's a developer changing an internal API. Private APIs are subject to change at _any time_ without notice because they are PRIVATE. That's what PRIVATE API means.


I've been saying this the entire time, and I've been usng this as the reason why Microsoft cannot ship a YouTube app. As I've mentioned to Thom multiple times.

I really don't understand the point you're trying to get at, and I don't think you're out to make a point beyond trying to get a couple of shots in.

Don't presume so much, when you know so little yourself.

Reply Parent Score: 2