Re: Comparison/gap analysis of reqs and APIs

Hi Alex, 

Thanks for your review and provide these valuable feedbacks. 
It is definitely great that any feedbacks are given to our draft. 

To explain some points we had considered: 
> channel.tracks 
In our draft, the way to display the TV stream is to get MediaStream from TVTuner then set to a Video tag. 
Therefore the tracks information and track switch would be performed by multitracks API of Video tag. 

> tuner.notifications 
We had decided to not consider the use case of hot plugging TV Tuner because we didn't see it on real TV product now. 

> emergency.notifications 
We are not sure the entire behaviour and the technical details of this use case yet. 

> recording & time shifting 
Firefox supported MediaStream Recording API. 

Thanks, 
Sincerely yours. 
----- Original Message -----

From: "Alexander Futasz" <alexander.futasz@fokus.fraunhofer.de> 
To: public-tvapi@w3.org 
Sent: Saturday, October 18, 2014 12:00:04 AM 
Subject: Comparison/gap analysis of reqs and APIs 



Hi everyone, 



on the wiki there is now a comprehensive comparison of our technical requirements against the Mozilla TV Manager API (proposed outside the CG, still WIP) and the older webinos TV Control API. 

https://www.w3.org/community/tvapi/wiki/Main_Page/Requirements_Mapping 




The summary is: 

· The older webinos API doesn’t cover most requirements 

· The Mozilla API covers almost all of them besides a few that could either be added or are not that important (subjectively) 



Open requirements missing from Mozilla’s draft (somewhat sorted by subjective importance): 

· channel.tracks – Would need to be added. 

· tuner.notifications – Existed in previous drafts of the API. Need to understand why it was removed. 

· tuner.signal-strength and scan.signal-strength – Could be added if deemed necessary? 

· emergency.notifcations – Would need to be added. 

· channel.search, .filter, .sort, .sequential – Would argue that these are not necessary for an API. If channel.available and channel.select requirements are fulfilled, then these can be modelled by the application or a support library. Otherwise they only add baggage to the interface. 

· recording and timeshift – Leave that to MediaStream Recording API, maybe try to contribute there to adapt to needs. Which browsers currently support it? 

· program.data.video – ?? 



Seeing how the Mozilla API addresses most requirements I strongly think it would be worth a shot to see what their editors think of e.g. contributing the API as a basis to be used for the CG draft or maybe even continue to develop the API inside the CG. Would be happy what everybody and especially the guys from Mozilla think about that. 



As a final note, I couldn’t check the requirements for cas and triggers as those are not my expertise. Everybody is welcome to fill the table for those requirements, they seem pretty high level to me and not absolutely mandatory for a TV API. I could be wrong though. 



Best regards 

Alex