1st radio-api

[AlexErk]

1st draft of the radio api

[AlexErk]

Dear all this is a 1st version in order to integrate teh Radio use cases into the current draft of the API. In general I've done the following:

1: Changed the names of all the interfaces, which are applicable for Radio and TV.

2: Introduced a ChannelAttributes interface and sub interfaces to handle technology specific channel attributes. IHMO this is needed for the different TV systems too.

3: Introduced a Application interface. This Application interface could handle the differen user applications, TV and Radio services might have.

Open Questions: 1: TVMediaStream should we rename it ?

2: There's a oneitbroadcasted EventHandler in Source why? I would assume, that when EIT data is available, it's handled via the getPrograms method in the Channel interface.

3: TVCICards is the last only TV named interface just because there are no CI cards in Radio

[tidoust]

Hello @AlexErk,

@stevem-tw kindly agreed to edit the spec. To ensure he start with "interesting" editing tasks as soon as possible, I offered to convert the spec first to the so-called WebIDL contiguous syntax (see issue #6) that ReSpec now requires.

It would be good to merge this Pull Request before I run the conversion though, as it touches on different parts of the spec. I think the main blocker at this stage is the absence of prefix for interfaces (issue #16). While the group discusses possible prefixes, could you rollback on your changes and re-introduce the TV prefix everywhere?

I believe we can merge the PR afterwards and continue discussing possible updates to these interfaces within the group and in subsequent PRs.

[tidoust]

@AlexErk I created a PR on your PR that re-introduces the TV prefix and leaves the rest untouched: https://github.com/AlexErk/tvcontrol-api/pull/1

If you can review and merge that PR on your fork, the update should appear here automatically.

[tidoust]

@chrisn asked:

Should we introduce more specific application type interfaces here. e.g. for the DAB/DVB User applications (Slideshow, DL, Journaline, HbbTV, MHEG)? Or are we happy with just delivering the applicationData to the developers.

That seems like a place in the spec where we would like others (or other specs) to be able to define extensions. A similar example that comes to mind is the work on the Generic Sensor API. From an IDL perspective, it defines a base Sensor interface and let other specs define concrete sensors interface that inherit from Sensor. It seems a good idea to follow the same path here.

I think my own preference would be to have application-specific interfaces

I agree. We probably do not want a fixed enumeration for application types in any case.

[chrisn]

A few more comments on these changes:

Is application data only available for channels being presented, or can the data from any channel be accessed? I'm wondering whether the application data should be more closely related to the TVMediaStream rather than the TVChannel interface.

Is the application data expected to be aligned temporally with the audio/video media? If so, we could look at using TextTrackCue, as TVMediaStream has support for text tracks. Maybe we could use DataCue to support application-specific data types.

I'm also worried that introducing an Application (or TVApplication) interface might be confusing, as elsewhere in the spec we use "application" to mean Web applications that use the TV Control API.

Having said this, I think we should merge this PR (together with Francois' changes) and raise separate issues for these questions.

[AlexErk]

1: I would assume, that application data is only to be presented for the channel they belong to.

2: Yes application datte (Slideshow and textmessges ) are aligened temporall with the audio. I would alos assume that for many other types is will be very likely. So the TextTrackCue might fit perfect for text messages.

3: I agree Application might be misleading. Suggestion "DataComponent"

[tidoust]

Hi @AlexErk,

Note that, to provide @stevem-tw with a spec in the "right" WebIDL format, as noted in a previous comment [1], I will merge my PR (to re-introduce the TV prefix) and your PR and run the conversion early next week. I would expect the discussion to continue and interfaces to evolve afterwards, of course!

[1] https://github.com/w3c/tvcontrol-api/pull/14#issuecomment-255354089