- From: <bugzilla@jessica.w3.org>
- Date: Wed, 27 Aug 2014 23:07:15 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25920 --- Comment #15 from David Dorwin <ddorwin@google.com> --- (In reply to Mark Watson from comment #14) > (In reply to David Dorwin from comment #12) > > (In reply to Mark Watson from comment #11) > > > As per comment #9, the change should not have removed the possibility for > > > the CDM to populate the destinationURL field. > > > > I don't think comment #9 says this. > > Well, that's what I understood during the discussion of this bug and would > certainly have objected at the time if the proposal was to remove the > possibility for the CDN to set the destinationURL. Apologies if that was my > min-understanding. Ah, you were saying that comment #9 did not describe the removal so it should have been restored. I interpreted it as saying that comment says we should restore it. Thanks for clarifying. > > Are there scenarios *not related to initData* that would use destinationURL > > in generateRequest()? If so, we should evaluate how they fit in an > > interoperable application before adding complexity to support them. > > The initialization exchange is one. In this case the application may just > need a one-bit indication from the CDM as to whether the message is to be > sent to the initialization server or the regular application server. The > destinationURL can be used for that (this is what I mean about the > destinationURL containing information used for routing - it may not be the > actual URL, but it can be something which selects from amongst a set of URLs > known to the application). It is unclear to me why the CDM should select a different server to perform initialization then ask the application to do the initialization. Initialization could a) be handled by the user agent with a central server, in which case it would not go through the EME APIs, or b) be handled in a per-application way via the EME APIs. In the latter case, why can't the initialization go through the same server (even if it is then handed off to another server). It seems wrong that the CDM should be able to tell the application to use a server that is not its own. The assumption for the other uses of destinationURL is that the URL comes from the license. In that case, the license server (likely controlled and configured by the application author) can specify a different URL for certain messages (i.e. heartbeat). With default URL removed, maybe a better solution would be to replace MediaKeyMessageEvent's "destinationURL" attribute with a "type" attribute, which would allow the application to select the appropriate server from its list of servers. This would work for normal messages, heartbeat, and initialization. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 27 August 2014 23:07:17 UTC