- From: <bugzilla@jessica.w3.org>
- Date: Mon, 25 Feb 2013 22:49:26 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20964 --- Comment #21 from Mark Watson <watsonm@netflix.com> --- (In reply to comment #17) > (In reply to comment #16) > ... > > My view is that this is not a bug, but a feature. And so we should close > > this bug. As Joe points out it's also true of the web platform as a whole. > > Joe has been challenged to prove this claim and has not done so. You > are welcome to addess this challenge? Please demonstrate how the > web platform can currently prevent the user storing content received > and presenting it in the future when the server from which the content > was received is no longer accessible? You have a rather narrow definition of 'content'. A user who plays a Facebook game whilst browsing facebook.com, for example, likely considers the game part of the 'content' of the page. That user would be totally unsurprised at the idea that the game is only available for as long as Facebook servers are available. The mooted ability to make a recording of the gameplay for later enjoyment might be rather underwhealming. The point is that the creator of a game or anything else on the web decides the functional split between client and server. Only services with no real-time server component - and there are plenty of games and other things like this - remain available to the user when the servers are no longer available. Some video services also do not require a real-time server component, but others - including that of my employer, Netflix - do. Again, users of a service like Netflix would be totally unsurprised at the idea that if their subscription or Netflix itself expires, they can no longer enjoy the content. You seem to be assuming that because a service is related to video it's reasonably to expect the company offering that service to conform to your preferred technical architecture - with no real-time server component. It's not. We choose a different design for well-founded business reasons and in alignment with common-sense user expectations. The ability to do so with EME is therefore a feature and this bug should be close. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 25 February 2013 22:49:28 UTC