Gap analysis for chartering the WG

From Web-based Signage Business Group
Jump to: navigation, search

Power Status Management

This API is for state transitions of signage terminal devices. Each status of the device and the transitions of them are described in Figure.

Power Status Control

This API manages the power status of the device and the panel

  • Power saving: Power-On to Stand-by
  • Turning off the panel: Power On to Display Off
  • Turning on the panel: Display Off to Power On

Power Status Scheduling

This API manages the scheduling of changing the power status of the device or panel

  • Scheduled resuming: Stand-by to Power-On

Remote Prompting

Controlling dialog boxes (promptings)

This function is not proper for API. So, the remote prompting is deleted from the draft charter. (22 Nov. 2016)

At the f2f meeting of the TPAC 2016, this category was not discussed in detail. For now, we don't have concrete APIs in this category. Is this category required in order to charter the WG? (Futomi, 2016-09-27)

Contextual Information

Signage Operational Information

This API allows us to get the device management information. (terminal identification, operational information)

  • Hardware serial number
  • Manufacturer name
  • Model number
  • Friendly name
  • Display Type (Panel, Projector, Tablet)
  • Screen Size (inch size)

Signage Functional Information

This API allows us to get the functional information. This function is used by player to fit content to other resolution or size of displays.

(content expression)

  • Resolution(Width, Height of display): Logical
  • Screen Size (inch size)

(Useful but difficult to create)

  • Capability
  • Codec
  • Resolution(Width, Height of display): Physical

Location API (TBD)

This API providing such information as Region Code, City, or Time Zone is useful for Region-based signage services such as signage in a Bus. However, Geo-Location WG has already provided some functions for these services, and we need gap analysis with them.(22 Nov. 2016)

I'm not sure what kind of location does this API exposes. Please elaborate this API, someone. (Futomi, 2016-09-27)

Network Information API

This API allows us to get the setting of the network (Network Administration) This API might be used in a multi-screen service (direct connection with other terminals such as HbbTV)

However, it is not mature to develop this API and to identify the use cases, so we continue to discuss further in BG or new WG. (23 Nov. 2016)

  • Type of network (Ethernet, Wi-Fi, etc.)
  • IP version (IPv4, IPv6)
  • IP address of the terminal
  • Subnet mask
  • IP address of the default gateway
  • DHCP (true or false)
  • IP address of the DNS
  • MAC address of the terminal
  • Link status (Up or not)

Gap analysis

At the f2f meeting of the TPAC 2016, the Network Information API developed by the Web Incubator CG was informed by Jay Kishibami.

Futomi's opinion (2016-09-27)

As far as I read the Network Information API developed by the Web Incubator CG after the TPAC, the API just exposes the connection type of the network in use by device (e.g. "bluetooth", "cellular", "ethernet", "wifi", etc.). In the other hand, Web-based Signage needs the IP address, MAC address, and so on. The connection type is just one of the demands.

Our options are:

  • We request our demands to be added to their Network information API to the Web Incubator CG
  • We develop our Network Information API except the type of network, rename our Network Information API to other name

Display Setting API

This API allows us to get and change the setting of the display (panel)

NOTE: We need Term of definition(Display or Panel, Screen (Projection))

  • Resolution (more investigation is needed)
  • Multiscreen Identification (need discussion about combination of UA, Windows and Screen (for example, 1 STB controlls 2 or 4 screen))

Unable to create enough function:

  • Dimming (controllable but inefficient to change)
  • Brightness (controllable but inefficient to change) especially needed by Korean Regulation
  • Contrast (unable to change)
  • Color space (depends on connection with STB)

Included in Media Element API and already implemented:

  • Panel volume (If speakers are equipped in the panel)
  • Panel mute status (If speakers are equipped in the panel)

NTP Server Setting API (Category is TBD)

Clock of terminal might be changed after rebooting.

This API just gets and sets the IP address or host name of the NTP server to the underlying OS. Signage operators sometimes want to change the address of the NTP server set in terminals. Current signage terminals can be set and only set IP address(or hostname).

If the operator manages a lot of terminals, changing the setting remotely is useful.

Synchronization of each terminal is main purpose. There are many methods, using NTP, Date Header or using Broadcasting method. A lot of discussion is needed before creating API, if we create API.(23 Nov. 2016)

  • NTP configuration (depends on underlying OS)

Ambient environment API

This API provides the measurements of the sensors equipped in the terminal.

There is no function we must create.(23 Nov. 2016)

Not implemented but unable to find use cases

  • Temperature
  • Humidity

Already defined in DAP

  • Ambient light
  • Proximity
  • Screen Capture

Might be addressed by using getUserMedia

  • Ambient Noise

Gap analysis

Futomi's opinion (2016-09-27)

These sensor has been addressed by the Device and Sensors WG. Ambient Light Sensor, Proximity Sensor, Accelerometer, Gyroscope, Magnetometer has been listed as their roadmap, the editor's drafts has been released. I think that such kind of APIs should be developed by the Device and Sensors WG. Screen capture API is provided by DAP and Web RTC.

Interaction with other devices

smartphone, camera, etc.

In our discussion, we can not find the use case for creating new API. And, we had better to concentrate operation aspect. So, we decide not to include this function in the charter of new WG. (23 Nov. 2016)


Gap analysis

Futomi's opinion (2016-09-27)

There are some technologies to interact with other device, such as BLE, NFC, QR code (via camera). APIs related to such technologies has been developed by other groups in W3C: