On Fri, Apr 25, 2014 at 8:12 AM, Marco Chen <mc...@mozilla.com> wrote: > Hi all, > > As a web platform, FxOS always follow the standard and join to create the > standard. > As a mobile OS, FxOS always tries to give user more great experience and > enrich their live then bringing in more devices and people into web. > As a device partner using mobile OS, I would like FxOS to support more > popular and common features in the market not the feature came or > implemented by standard but not be supported in the market. > As a user, I would expect my device and OS can perform most of popular > service in the market now. (and actually user don't care it's standard or > not) > > My question is > For a new feature, firstly people would like to find any current standards > which can be combined to achieve the feature even this combination is more > complicated. > But why don't we investigate a new one to let things go easily or leverage > the existing way in the market now? > > Example 1: HTTP Live Streaming > According to MSE, gecko removed to support DASH and move it to be a > dash.js + MSE. > Then people expected that HLS should be implemented by something like > hls.js + MSE because it can be adapted to standard and scalable on different > manifest mechanisms. > But the practical fact is that the current content providers and their > apps expected m3u8 URL can be put into src of video tag then starting to > enjoy video. > Therefore the ideal way using standard to support HLS is no useful for > many popular content services in the market. > Force them to adapt our way or let things to easily since there is no > standard on HLS to push hls.js + MSE.
I don't know enough about MSE or HLS to comment here. I would recommend that you talk to the media team. > Example 2: DLNA > Opera introduced Network Device Discovery API (working draft) and there > are UDP/TCP Web Socket are introduced too. > So people started to think DLNA can be adapted by these Web API and some > implementation on Web Content (ex:upnp_av_profile.js + UDP/TCP Web Socket). > But the practical fact is that device partner want to leverage a 3rd party > library into their platform which is confirmed to pass the certification and > guaranteed stability. > Also 3rd party library can cover others like DTCP which is no standard web > api announced to cover yet. (maybe can be covered by some combination) > Force device partner to take back the effort or let them have a way to > leverage existing way in the market now? The fact that a partner wants to use a particular library to implement DLNA is not a good enough reason to add a DLNA API to our platform. Keep in mind that additional APIs are terribly expensive over time since generally we have to maintain them forever. Additionally we generally should try to avoid having partners ship their own implementations of various APIs. That always runs the risk that an API will behave differently on different devices which means that we're fragmenting our platform. Is there a reason that this partner couldn't use emscripten to compile their library so that it runs inside their app and uses UDP/TCP socket APIs? / Jonas _______________________________________________ dev-b2g mailing list dev-b2g@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-b2g
