API investigations

This section contains the results of the investigations on APIs of the different categories and acts as background information to the APIs supported by Webinos.

Based on Webinos requirements/use cases and architecture needed APIs are identified. Potential existing APIs from W3C, WAC and elsewhere are investigated and analyzed. If no existing APIs that could fulfill the Webinos requirement is found high level requirements on a new API to be specifed within the Webinos project are stated.

HW Resource APIs

Description

This section contains investigation results on APIs for access to HW related resources.

Resources

Primary contributor/editor for this API category: Telecom Italia
Supporting contributors/reviewers: SEMC / AmbiSense / Fraunhofer / BMW

APIs based on existing standards/implementations

Device Orientation API

Description: Information about the physical orientation of a device, typically implemented by using information from accelerometer, magnetometer and gyro.
Requirement/architectural reference: CAP-DEV-SEMC-009:Webinos SHALL provide means for applications to access device physical orientation
Phase: Webinos phase 1
Webinos responsible: Claes Nilsson/SEMC
Candidate API Short Description Implementation Status Gaps Notes Decision
W3C DeviceOrientation Event Two DOM event types that provide information about the physical orientation of a hosting device.
- The first event is a simple, high-level source of information about the physical orientation of a device, expressed as device rotation in angles around 3 different axes. While the spec is agnostic to the source of information, this is typically implemented by combining information from an accelerometer and a magnetometer.
- The second event provides direct access to motion data from an accelerometer and gyroscope and is intended for more sophisticated applications. Acceleration is expressed in m/s2 and rotation rate is expressed as degrees/s.
iOS 4.2
Android 3.0
Chrome 7
Opera Mobile for Android (experimental)
No gaps identified Webinos will use this API
WAC 2.0 Device APIs: The orientation module Device orientation information, expressed as device rotation in angles around 3 different axes. Existing 3rd party implementations of WAC WRT clients from Obigo, Opera, Aplix, etc, for Android and other platforms No gaps identified
WAC 2.0 Device APIs: The accelerometer module Provides access to the device accelerometer information expressed in m/s2 in 3 different axis. Existing 3rd party implementations of WAC WRT clients from Obigo, Opera, Aplix, etc, for Android and other platforms The API does not provide a means to separate acceleration due to movement from acceleration due to gravity, which could be provided by devices containing both an accelerometer and a gyroscope.

Generic SensorActuator API

Description: It currently exist a set of APIs tailored for specific sensor data. Examples are the W3C Geolocation API (GPS), the W3C DeviceOrientation Event (accelerometer etc) and the W3C HTML Media Capture API (camera, microphone). However, there is also a need for a generic/extensible API to get access to sensors. This is needed as new types of sensors are frequently introduced. These sensors could be:

The API should be agnostic to the location of the sensors and to underlying discovery and connection methods.

Requirement/architectural references:

Phase: Webinos phase 1

Webinos responsible: Claes Nilsson / SEMC

Candidate API Short Description Implementation Status Gaps Notes Decision
W3C The System Information API A high-level API to system information and sensors.
- A set of simple sensor APIs is included in the specification
- Agnostic to underlying sensor access method
- All APIs are asynchronous.
- Simple get value or watch for continuous "callbacks" when the values change or when the values reach below or above certain defined threshold values.
- The sensor properties currently included in the specification are:
AmbientLight
AmbientNoise
AmbientTemperature
AmbientAtmosphericPressure
Proximity
No known implentations Gaps:
- For each additional sensor a new sensor property has to be defined
- Reading only, writing data or control sensor not supported
- Only one single value for each sensor property, compound data patterns not supported
This API has been criticized within W3C and the future for this API is uncertain. See: Sys Info feedback. There is a proposal to create a set a smaller discrete APIs to specific system properties such as network and battery. For sensors a set of discrete event based APIs similar to the DeviceOrientation Event has been proposed. In addition it is proposed to break out the current sensor part from The System Information API to create a separate "Generic sensor API".
The Bondi sensor Module - Version 1.5 *Sensor API Sensors are classified by type. Sensor type names are defined Strings, and creation new type names must be centrally defined (by the owner of this API definition) Unknown
WAC 2.0 devicestatus module Access to various information regarding the status of the device.
- All APIs are asynchronous.
- Simple get value or watch for continuous "callbacks" when the values change or when the values changes a certain percent.
- Compound data patterns supported
Existing 3rd party implementations of WAC WRT clients from Obigo, Opera, Aplix, etc, for Android and other platforms Gaps:
- Extensions to the WAC vocabulary is needed to cover not only internal device status but also internal and external sensors.
- Reading only, writing data or control sensor not supported
Symbian WRT Platform Service 2.0 Sensors API Access to sensor data:
- Asynchronous event based
- Compound data patterns supported
Nokia/Symbian WRT Gaps:
- Extensions, i.e. additional sensor channels need to be specified for all sensors supported
- Seems as not possible to trigger on threshold values
- Reading only, writing data or control sensor not supported

Decision:

A new generic sensor API will be specified. This API is inspired by W3C DeviceOrientation Event Specification, W3C Battery Status Event Specification and the Android sensor API. For phase 1 only reading, not writing, sensor data will be supported.

Editor: Claes Nilsson / SEMC

High level Requirement Notes
Find sensors in device, locally connected to the device or in the cloud
Configure a selected sensor
Provide sensor data as a DOM event

Microphone API

Description: Capture audio samples from microphone
Requirement/architectural reference: CAP-DEV-SEMC-004
Phase: Webinos phase 1
Webinos responsible: Stefano Vercelli / Telecom Italia

Candidate API Short Description Implementation Status Gaps Notes Decision
W3C Media Capture Api (see
http://www.w3.org/TR/media-capture-api/)
Api for capturing audio/video/image data W3C working draft. Implemented by Phonegap project. See PhoneGap Capture Only useful for capturing media files, doesn't give access to live stream Webinos will use this API due to security and remote access reasons
W3C HTML Media Capture Api (see
http://www.w3.org/TR/html-media-capture/)
Defines a new interface for media files, a new parameter for the accept attribute of the HTML input element in file upload state, and recommendations for providing optimized access to the microphone and camera of a hosting device W3C working draft, under implementation for Android 3.0 and a Bug tracking implementation in WebKit Not an API in itself, more an add-on to file upload. Only useful for capturing media files, doesn't give access to live stream
WhatWG Device Element (see
http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#devices) and Stream API
Provides a Stream API to be used on top of user-selected sources of input.
Note: Probably replaced by getUserMedia
WhatWG draft, experimental impl. in WebKit (e.g. Ericsson's)
WhatWG getUserMedia (see
http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html)
Early draft in WHAT WG. Provides a Stream API to be used on top of user-selected sources of input. Experimental implementation for Opera Mobile Work in W3C started in Web RTC WG Proposed to support in phase 2

Camera API

Description: Capture video stream from device camera
Requirement/architectural reference: CAP-DEV-SEMC-005
Phase: Webinos phase 1
Webinos responsible: Stefano Vercelli / Telecom Italia

Candidate API Short Description Implementation Status Gaps Notes Decision
WAC 2.0 camera module (see
http://specs.wacapps.net/wac2_0/feb2011/deviceapis/camera.html)
Interface to device camera for capturing video or image Implementations of WAC WRTs by Obigo, Opera, Aplix, Borqs
W3C Media Capture Api (see
http://www.w3.org/TR/media-capture-api/)
Api for capturing audio/video/image data W3C working draft. Implemented by Phonegap project. See PhoneGap Capture Only useful for capturing media files, doesn't give access to live stream Webinos will use this API due to security and remote access reasons
W3C HTML Media Capture Api (see
http://www.w3.org/TR/html-media-capture/)
Defines a new interface for media files, a new parameter for the accept attribute of the HTML input element in file upload state, and recommendations for providing optimized access to the microphone and camera of a hosting device W3C working draft, under implementation for Android 3.0 and and a Bug tracking implementation in WebKit Not an API in itself, more an add-on to file upload. Only useful for capturing media files, doesn't give access to live stream
WhatWG Device Element (see
http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#devices) and Stream API
Provides a Stream API to be used on top of user-selected sources of input.
Note: Probably replaced by getUserMedia
WhatWG draft, experimental impl. in WebKit (e.g. Ericsson's)
WhatWG getUserMedia (see
http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferencing-and-peer-to-peer-communication.html)
Early draft in WHAT WG. Provides a Stream API to be used on top of user-selected sources of input. Experimental implementation for Opera Mobile Work in W3C started in Web RTC WG Proposed to support in phase 2

Here is an analisys of Media Capture and HTML Media Capture. Notice that both apis require the File api (http://www.w3.org/TR/FileAPI/).

W3C HTML Media Capture api

It looks like it has been designed for uploading pictures/audio/videos (it uses the HTML input tag). A "file picker" is launched and it can select an existing file or take a new picture/audio/wideo (I guess using an external app). No options are available before launching the app. It looks like there's no way to know at js level when the picture/audio/video has been taken. It is not clear if the picture/audio/video is saved on the filesystem.
Supposing we want an app that takes a picture and displays it, here's a theorical code snippet with HTML Media Capture:


...
<script type="text/javascript">
function displayImage() {
var captureInput = document.getElementById('capture');
var file = captureInput.files[0];
document.getElementById("myImage").src = file.url;
}
</script>
...
<body>
...
<input type="file" accept="image/*;capture=camera" id="capture">
<img id="myImage" src="defaultImage.jpg"/>
...
</body>

Notice that the displayImage() function should probably be invoked explicitly by the user.

W3C Media Capture api

It uses an external app to take the picture/audio/video. A few options are available before launching the app ("limit", that is the number of pictures/videos/audios to take; the duration of the video), and a few have been proposed (height and width of image, format of the output, duration of audio). Error and success callbacks are available. It is not clear if the picture/audio/video is saved on the filesystem (it depends on the external app?).
Supposing we want an app that takes a picture and displays it, here's a theorical code snippet with Media Capture:


...
<script type="text/javascript">
function takePicture() {
navigator.device.capture.captureImage(successCB, errorCB, { limit: 1 }); //it takes 1 picture and exits
}
fucntion successCB(data) {
document.getElementById("myImage").src = data[0].url;
}
function errorCB(err) {
alert("an error occurred");
}
</script>
...
<body>
...
<button onClick="takePicture()">Take picture</button>
<img id="myImage" src="defaultImage.jpg"/>
...
</body>

Geolocation API

Description: Access to device location information
Requirement/architectural reference: CAP-DEV-SEMC-008
Phase: Webinos phase 1
Webinos responsible: Stefano Vercelli / Telecom Italia

Candidate API Short Description Implementation Status Gaps Notes Decision
W3C Geolocation API Access to device location regardless of the source of information (it may be GPS, GSM/CDMA cell id, wifi, ...) Implemented in modern browers such as Chrome, Firefox, iOS, Android, Opera Mobile, etc No gaps identified A 2nd version of the API will also provide civic address information Webinos will use this API
GSMA OneAPI Location RESTful API A RESTful API for querying the location of one or more mobile devices. Open Source Reference Implementation in PHP/Java
Commercial Pilot in Canada
Possibly no GPS support. This method asks the network for location based on the MSISDN of the device

Devicestatus API

Description: Access to device status informations
Requirement/architectural reference: CAP-DEV-SEMC-012, CAP-DEV-SEMC-013
Phase: Webinos phase 1
Webinos responsible: Stefano Vercelli / Telecom Italia

Candidate API Short Description Implementation Status Gaps Notes Decision
WAC 2.0 devicestatus module Access to various informations regarding the status of the device Implementations of WAC WRTs by Obigo, Opera, Aplix, Borqs An extension of the WAC vocabulary is needed to cover all info needed (CPU load, system temperature, audio/video codecs capabilities, input devices, ...) WAC Device Status Vocabulary This API will be used, with an extended vocabulary
W3C System Info API "Access to various properties of the system which they are running on" Not implemented This API has been critiized within W3C and the future for this API is uncertain. See: Sys Info feedback. There is also a proposal to rework the sensor APi to a set of event based APIs according to the DeviceOrientation Event. For example see see http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0122.html and http://lists.w3.org/Archives/Public/public-device-apis/2011Mar/0123.html
GSMA OneAPI 2.0 Device Capability A RESTful API to query capabilities of a device. unknown Provides access to static information only like hardware and software platform properties. No access to e.g. battery status.

TV and STB control API

Description: Control TV/STB via API so other devices can act as a remote control.
Requirement/architectural reference:

Phase: Webinos phase 1
Webinos responsible: Fraunhofer

Candidate API Short Description Implementation Status Gaps Notes Decision
Open IPTV Forum Rel 2 Vol 5 Declarative Application Environment (See pdf) Based on CE-HTML this includes a JavaScript API for apps on a TV/STB. Supports e.g. app installation and management, channel configuration, video playback, recordings, etc. Unknown. TV sets supporting CE-HTML exist. Addresses much more than what is needed to access/control features related to the broadcast. The HbbTV standard is also based on this.
BBC Universal Control API A RESTful API which returns XML responses to GET requests to control TV and STB. BBC prototypes (See blog announcement). There seems to be no way to get access to the broadcast stream; e.g. to embedded it into an app. Discussion on the mailing list wether all device features should be exposed via API on the server (TV/STB, TV watching as "app") and client (e.g. smartphone as remote control) or should they be just accessible to clients. For the former the proposed data model may be too strict and limiting. See announcement and following discussion in replies
The Dreambox Webinterface API A RESTful API that is used on the DBox2 STB (for DVB-S, -C). The API allows to control volume, audio tracks, channel, EPG, messaging, etc. Responses are in XML. DBox2 Linux Distro No support for accessing the broadcast stream to embedded in own app, instead a control functionality only. Used only by dreambox hardware. A community based project.

Decision: A new TV control API will be specified. This API makes available access to TV channel streams that can then be plugged into a HTML5 HTMLVideoElement. Alternatively, it also provides means to control the channel playback of a native hardware component.

Deviceinteraction API

Description: Access to apis for interacting with the end user
Requirement/architectural reference:
Phase: Webinos phase 1
Webinos responsible: Stefano Vercelli / Telecom Italia

Candidate API Short Description Implementation Status Gaps Notes Decision
WAC waikiki deviceinteraction module Interaction with the user through features like device vibrator and screen backlight Implementations of WAC WRTs by Obigo, Opera, Aplix, Borqs This API will be used as W3C device interaction API is not yet in place.
Chrome extension for UI interaction Chrome offers several apis for customizing the browser UI (add menus, tabs, desktop notifications)
Bondi User Interaction module Allows customization of menus related to specific phone keys as well as control of beeping, vibration, backlight, screen orientation

Barcode API

Description: APIs for decoding barcodes using the camera of the device.
Requirement/architectural reference: CAP-DWP-ambiesense-51
Phase: Webinos phase 1
Webinos responsible/editor: Stefano Vercelli / Telecom Italia.
Contributor: Hans Myrhaug, AmbieSense Ltd

Candidate API Short Description Implementation Status Gaps Notes Decision
ZXing ZXing (pronounced "zebra crossing") is an open-source (Apache 2.0 licensed), multi-format 1D and 2D barcode image processing library implemented in Java. The focus is on using the built-in camera on mobile phones to photograph and decode barcodes on the device, without communicating with a server. A JavaScript library based on ZXing is proposed. In reality ZXing is becoming the open source industry standard for barcode recognition in mobile applications and there are fully working implementations on Android and other mobile platforms. See here for a way to use the library on a mobile device on a webpage. There are concerns that a JavaScript port might be slow. This (possibly 3rd party provided) library would not be part of a device API but apps could choose to include this library or not based on whether they need the functionality. See Measurements that states it takes 40-60 ms to process the image on a Gingerbread Android device with a 1GHz processor. That indicates that porting of Zxing to JS is probably feasible. Bar code reading will be supported through a JavaScript port of the ZXing Java library. This means that bar code reading is out of scope for further work within WP 3.2

APIs for which no existing standards/implementations exist

Vehicle API

Description: Provides access to vehicle proberties (e.g. current speed, mileage, fuel consumption)
Requirement/architectural reference: Extension Handling
Phase: phase 1
Webinos responsible/editor: Simon Isenberg, BMW
High level Requirement Notes
Access to the Automotive API MUST be authorized based on applications
In case of a denied access to the vehicle API the requesting application SHALL be informed.
The following car properties SHALL be available read-only for applications
- model
- speed
- current fuel consumption
- average fuel consumption
- trip kilometers/miles
- total kilometers/miles
- current units
- gear
- engine status
- position of the steering wheel
An application MUST be able to bind to car properties and be infomend about the new value
An API for communicating with the in-car navigation system SHOULD be available
It SHALL be possible to set time intervals for applications to access a car property

A possible solution is to see this api as an extension of devicestatus for vehicles.

Candidate API Short Description Implementation Status Gaps Notes Decision
WAC 2.0 devicestatus module Access to various informations regarding the status of the device Implementations of WAC WRTs by Obigo, Opera, Aplix, Borqs An extension of the WAC vocabulary is needed (for example you can add a new Aspect ("vehicleInfo") with properties "model", "speed", ...)
W3C System Info API "Access to various properties of the system which they are running on" W3C working draft This API has been critiized within W3C and the future for this API is uncertain. See: Sys Info feedback. There is also a proposal to rework the sensor APi to a set of event based APIs according to the DeviceOrientation Event. Comment by Claes/SEMC: Seems as W3C is taking an event model route now for sensors. Consider to make a DOM level 3 event model based Vehice API similar to DeviceOrientation Event specification and Battery Status Event specification

Decision: A separate Vehilce API will be specified. The API will provide read-access to car data in the first phase of the project. This API is inspired by W3C DeviceOrientation Event Specification, W3C Battery Status Event Specification.

Background information on the vehicle API for the 3.2 deliverable

In the browser/web domain no developer API has been specified to access vehicle data so far. In other domains there are a few APIs publicly available which provide access to vehicle data, but haven't been largely used yet.

In JSR 298 the OSGI vehicle expert group (VEG) defined a Telematics API for JAVA. This API provides access to the vehicle data for JAVA Me developers. The OSGI VEG was discontinued in 2006. The API has not been refined afterwards. The specification is available at: http://jcp.org/en/jsr/summary?id=Telematics.

In other EU founded projects the Serial Line Automotive Protocol (SLAP) introduced by Volkwagen has been used to retrieve vehicle data. The SLAP is based on XML-formatted messages to request and receive vehicle data.

Due to the lack of an feasible API for vehicle data inside the browser domain, we define a new API which provides read-only access to the following data:

Furthermore the API provides access to the following functions:

The API is aligned to the current W3C's approach of event based APIs. The vehicle API does not provide information about the geolocation, speed and acceleration. These attributes are already accessible using the W3C Geolocation API for speed and position and the W3C Device Orientation API for acceleration.

In the first iteration of the project the vehicle API focuses on the access of read-only data, which is available on the infotainment bus due to the fact that the in-car headunit is usually connected this bus system as shown in the following depiction.

For the second iteration of webinos the extension of the vehicle API to data outsite of the infotainment bus (MOST) as well as more methods for interacting with the vehicle system seems beneficial.

NFC API

Near Field Communication (NFC) is an international standard (ISO/IEC 18092) that specifies an interface and protocol for simple wireless interconnection of closely coupled devices operating at 13.56 MHz. The overall application scenario is to hold a device close to a wireless tag to exchange some digital information or data. Alternatively, the scenario is to hold two devices close to each other in order to exchange some information or data between them. NFC is also sometimes referred to as contactless communication.

There are three use case categories for NFC driven by NFC Forum, www.nfc-forum.org:
  1. NFC peer to peer communication, with use cases for sharing data between devices, and for pairing with other devices.
  2. Tag R/W mode, with use cases for any application provider proposition integrate real world objects with Internet and applications.
  3. Card Emulation mode, is to move the existing smart cards that you have in your wallet today into the phone and make use of contactless NFC connections.

All three propositions addressed by use cases of the NFC forum are indeed relevant to the webinos user stories and use cases. Ideally, webinos application developers will therefore need all of these implemented. Thus, in terms of webinos implementaiton priority, we recommend the following order: first 2, then 1, and then 3, because our target group is application developers, and most of them will most likely be doing 2 in the beginning. 1 will become increasingly common when there are a lot of smartphones with NFC capabilities around in the market. Currently, in June 2011, the following NFC enabled devices are being sold in the mass market: Samsung Nexus S and Nokia Oro. The Samsung Galaxy S2 and the Nokia C7 will also be shipped with NFC capability.

Candidate API Short Description Implementation Status Gaps Notes Decision
Android NFC Read write mode is complete. Peer to peer mode is being implemented This is our choice because Android is now shipped more than iPhone, the activity is high Android NFC, and the license is Apache 2.0
Open NFC There are several versions for various platforms becoming available. The information about what is being implemented is unclear. This is not a choice because the Android implementation is based on the Android NFC API, and it is unclear how much activity this open source project.
Libnfc The implementation is in C and can be cross compiled for different operating systems. This is not our choice, because of the LGPL license.
J2ME (JSR-257) NFC The implementation is complete several years ago. Due to the current shift in the market, it is less likely that there will be any peer to peer mode supported. This is not our choice, because of the shift from J2ME enabled devices towards Android in the current market.
QT Mobility NFC The implementation is complete. Due to the Nokia announcement on the Microsoft alliance, this seems more risky in the long term.
Symbian NFC The implementation is complete. Due to the Nokia announcement on the Microsoft alliance, this seems more risky in the long term.

Decision: An NFC API will be specified within Webinos.

Requirement/architectural reference: TBD
Phase: Phase 1
Webinos responsible/editor: Hans Myrhaug / AmbiSense, Stefano Vercelli / TIM
High level Requirement Notes
Tag R/W mode Based on Android NFC API Gingerbread
NFC peer to peer communication mode Based on Android upcoming NFC API

Below is the proposed roadmap for the webinos API implementation. It seems clear that NFC peer to peer it will be supported on Android and
that it already is supported on both QT and Symbian. Thus, we believe that NFC peer to peer should also be supported by webinos after the NFC read and write capabilities (v=implemented, x=not yet implemented).

Proposed roadmap for implementation of the webinos NFC API Phase I Phase II
Register to launch application v v
Launch application on a specific NFC tag type v v
Launch application on connection to a specified service name (LLCP) x v
Listening to NFC discovery events v v
An NDEF tag has been discovered v v
A specified NDEF record type has been discovered v v
An NFC target has been detected v v
Reading and writing to NFC tags v v
Read NDEF messages and records from an NFC tag v v
Write NDEF messages and records to an NFC tag v v
Peer to peer communcation between NFC devices x v
Open connection to an NFC device (LLCP) x v
Send data to an NFC device (LLCP) x v
Receive data from an NFC device (LLCP) x v

Application Data APIs

Description

This section contains investigation results on APIs for access to application data.

Resources

Primary contributor/editor for this API category: Fraunhofer
Supporting contributors/reviewers: SEMC / W3C

APIs based on existing standards/implementations

See W3C current state of mobile web app technologies: data storage as a good starting point.

Contacts API

Description: Access/use the native contact application and its data. e.g. the contact application of a mobile device with Android or a fixed PC where Outlook is installed.
Requirement/architectural reference: Phase: 1
Webinos responsible: Fraunhofer
Candidate API Short Description Implementation Status Gaps Notes Decision
WAC 2.0 Device APIs: The contact module A JavaScript API to access multiple address books to add, update, delete or search for contacts. Fraunhofer MWR prototype (partial)
W3C DAP Contacts API A JavaScript API for finding contacts. Adding or updating contacts should be done via existing web platform APIs (e.g. attach a vcard string or file to an html anchor element). W3C ED
Mozilla Labs experimental Firefox add-on (See latest release announcement)
Bug tracking implementation in Webkit
The experimental Firefox add-on lags behind the DAP API draft (documented here). It also adds a service API for limited interaction with social web services. webinos will adapt this API from W3C - additions necessary due to webinos specific issues are listed below this table
PhoneGap Contacts API A JavaScript API for creating, updating and search for contacts. Android
BlackBerry WebWorks (OS 5.0 and higher)
iOS
Nokia Platform Services 2.0 Contacts API A JavaScript API for accessing and managing contact information in the default contact database. Symbian WRT 1.1

webinos specific additions
The W3C Contacts API specification defines the concept of a user's unified address book - where address book data may be sourced from a plurality of sources - both online and locally. However, the selection of sources for this unified address book is out of scope for the W3C Contacts specification. For the multi-device useability of webinos, a function needs to be added that allows the retrieval of a list of contacts across devices using search/discovery criteria, most likely be based on the Webinos ServiceDiscovery module.

Calendar API

Description: Access/use to native calendar application and its data, e.g. the calendar application of a mobile device with Android or a fixed PC where Outlook or Thunderbird are installed.
Requirement/architectural reference: Phase: 1
Webinos responsible: Fraunhofer
Candidate API Short Description Implementation Status Gaps Notes Decision
WAC 2.0 Device APIs: The calendar module A JavaScript API to access multiple calendars defined as set of events that can be created, updated, deleted or searched for. Fraunhofer MWR prototype (partial)
W3C DAP Calendar API A JavaScript API for finding events. Adding or updating events should be done via existing web platform APIs (e.g. attach file with *.ics or *.ical extension to an html anchor element). W3C ED webinos will adapt this API from W3C - additions necessary due to webinos specific issues are listed below this table
Nokia Platform Services 2.0 Calendar API A JavaScript API for accessing, creating and managing calendar entries in the default calendar. Ability to subscribe to calendar entries being added, modified, deleted. Symbian WRT 1.1

webinos specific additions
The W3C Calendar API specification is designed to be agnostic of any underlying calendaring service sources. However, the selection of sources for this calendar information is out of scope for the W3C Calendar specification. For the multi-device useability of webinos, a function needs to be added that allows the retrieval of a list of calandar data across devices using search/discovery criteria, most likely be based on the Webinos ServiceDiscovery module.

Messaging API

Description: Send and receive messages of type email, SMS, MMS.
Requirement/architectural reference: Phase: 1 (2 for instant messaging functionality)
Webinos responsible: Fraunhofer
Candidate API Short Description Implementation Status Gaps Notes Decision
W3C DAP Messaging API A JavaScript API for sending SMS, MMS and email based on URL schemes. Supports attachments. W3C ED As of May '11 no reading or subscribing of messages is supported. Possibly planned for later API revisions. Consider extending this API for reading and subscribing as well.
WAC 2.0 Device APIs: The messaging module A JavaScript API to send, search for and subscribe to SMS, MMS and email messages. Fraunhofer MWR prototype (partial, only sms sending) webinos will base the Messaging API on the WAC/BONDI API due to the availability of receiving messages - an extension of the W3C API would most likely resemble the WAC API, so it is more convenient to start with that. webinos specific remarks follow this table.
GSMA OneAPI SMS, MMS RESTful Version 1.0 (pdf) A RESTful API that allows sending and receiving of SMS and MMS. Open Source Reference Implementation in PHP/Java
Commercial Pilot in Canada
Uses application/x-www-form-urlencoded and application/json for requests and application/json for responses.
Nokia Platform Services 2.0 Messaging API A JavaScript API that allows the sending, retrieving and managing of SMS, MMS and email messages. Symbian WRT 1.1

webinos specific changes
In addition to the message types e-mail, SMS and MMs, the webinos Messaging API also supports an 'Instant Messaging' (or 'Twitter'-style) type of sending and receiving messages. These are handled similar to SMS messaging, but require a different addressing scheme. Depending on the underlying messaging service, the retrieval of previous messages
might or might not be possible. To a certain extent, IM-type messages can also be used for sending text based notification messages to devices and applications as well as to users.
To support this, the basic WAC API has been extended by adding a fourth messaging type and an onInstantMessage(in OnIncomingMessage messageHandler) function. This has been done for phase 1 of webinos to allow experimentation, with a more specific and well defined set of messaging modi (e.g. Notifications) to be determined for phase 2.

Filesystem API

Description: Access to device filesystem
Requirement/architectural reference: CAP-DEV-SEMC-002, CAP-DEV-SEMC-003, CAP-DEV-SEMC-014
Phase: 1
Webinos responsible: Stefano Vercelli / Telecom Italia

Candidate API Short Description Implementation Status Gaps Notes Decision
WAC 2.0 Device APIs: The filesystem module A JavaScript API to access device filesystem Implementations of WAC WRTs by Obigo, Opera, Aplix, Borqs
W3C File API & FileReader API Interface to read user-selected files Firefox 3.6+
Google Chrome 7+
No gaps identified Webinos will implement this api
W3C File API: Writer A JavaScript API to write files TBD, spec as early W3C WD No gaps identified Webinos will implement this api
W3C File API: Directories and System A JavaScript API to navigate file system hierarchies W3C working draft Webinos will implement this api
PhoneGap File API A JavaScript API to access a mobile device filesystem for reading and writing files. Android
BlackBerry WebWorks (OS 5.0 and higher)
iOS

Multimedia/Gallery API

Motivation for a Gallery API:

There has been discussion as to whether a gallery is required and whether file access alone is enough. The rationale being that all media files are encapsulated as files.

There are several reasons why a gallery it would be a good idea:

Description: Access to media type files (audio, video, image) and playback.
Requirement/architectural reference: Phase: 1
Webinos responsible: Fraunhofer
Candidate API Short Description Implementation Status Gaps Notes Decision
HTML5 <video> element
HTML5 <audio> element
An HTML API to playback video and audio files and streams. W3C WD implemented with varying supported codecs in:
Firefox 3.6+
Firefox Mobile
Google Chrome 3+
Android Webbrowser (not inline)
Apple Safari 5+
Internet Explorer 9
Nokia Platform Services 2.0 Media Management API A JavaScript API to obtain a list of media files and their properties. Symbian WRT 1.1
W3C Gallery API A JavaScript API for searching in multiple gallery objects for media files. unknown Webinos will adapt this API from W3C - changes necessary due to webinos specific issues are listed below this table
PhoneGap Media API A JavaScript API to playback (and record) audio files on a mobile device. Android
BlackBerry WebWorks (OS 5.0 and higher)
iOS
Playback part obsolete because of HTML5 <audio>, <video>.
WAC 1.0 AudioPlayer A JavaScript API that can playback audio files and streams. Opera Widget Runtime for Android Obsolete because of HTML5 <audio>

webinos specific changes
Unlike Contacts and Calendar, the W3C Gallery API already provides a getGalleries method that allows access not only to local, but also to external galleries. While it might be useful to add a "webinos.findServices(user, "Galleries"...)" method as well (for consistency with Calendar and Contacts), this is just a possible addition, but not a necessity.

Payment API

Description: And API to charge users for apps/in-app-purchase/app-usage.
Requirement/architectural reference: [State reference to Webinos requirement or architectural component, interface, specification etc]
Phase: 1
Webinos responsible: Fraunhofer
Candidate API Short Description Implementation Status Gaps Notes Decision
GSMA OneAPI Payment RESTful Version 1.0 (pdf) A RESTful API to enable to charge mobile subscribers for web application usage or content. Open Source Reference Implementation in PHP/Java
Commercial Pilot in Canada
Uses application/x-www-form-urlencoded and application/json for requests and application/json for responses.
PayPal Direct Payment API (Description) A SOAP based API to allow payments from web applications using PayPal as a service provider. Java, ASP.NET and PHP wrappers/SDKs available from PayPal SDK site (https://www.paypal.com/sdk ) Specific to one payment service provider.
JSR-000229 Payment API (PDF download) Java specific architecture for payment handling, unchanged since 2005. Architecture quite Java specific, difficult to map to other languages/architectures. No detailed payment functionality specified (payment itself is only via a product name, which needs to be known to the payment provider, hence essentially only direct payments to shops (payment service provider is equal to product provider) is possible)
Android In-app Billing API (http://developer.android.com/guide/market/billing/index.html) Billing API that links in-app purchasing to the Android Market account. Android SDK API accessing the an Android Market service. Useful API, but specific to Java and Android Market.

webinos specific changes
Since none of the existing solution provides a sufficiently generic payment solution, webinos will define a generic and simple shopping basket based solution that can be mapped to different underlying payment systems to provide a systems that can address payments on platform bound payment solutions as well as open payment services.

Communication APIs

Description

This section contains investigation results on APIs for communication with other devices, other applications and servers.

Resources

Primary contributor/editor for this API category: Samsung
Supporting contributors/reviewers: SEMC / ISMB / VisionMobile

APIs based on existing standards/implementations

Socket Communication

API's mentioned in this section can be used by application developer to connect to application resources once the device discovered are presented and connected.

Phase 1

Description: To establish communication between two webinos devices.
Requirement/architectural reference: CAP-DEV-SEMC-006 webinos SHALL provide means for applications to execute streamed real-time interactive bi-directional communication with two or more other webinos applications running in the same device or running in different devices.
Phase: Webinos Phase 1
Webinos responsible:

Candidate API Short Description Implementation Status Gaps Notes Decision
W3C HTML5 WebSockets WebSocket provides: Bi-directional communication between client and server side process, multiplex various WebSockets together in one socket, and no problem with network protected by firewall as access is done on port 80/443. Supported in Chrome and Safari. Partly supported in Firefox and Opera No raw communication mechanism supported which leads to a requirement of proxy. It has problem with update command in transparent proxies which can result in changing the contents of cache. It has been revoked in Firefox and Opera. It is relevant but only WebSockets is not suffice but a combination of various technologies suits better. node.js, hides detail about underneath communication mechanism It is already supported in modern browser and there is no need of Webinos specific implementation
W3C HTML5 Server-Sent Events Server sent is designed to send messages from server and to support this it uses a push technology, it introduces DOM object event on which events are sent directly. It supports automatic reconnection. It is used as an alternative to XMLHttpRequest. It is implemented in all major browsers It is only relevant for receiving updates from Server. Main difference with WebSockets, it does not support bi-directional communication and use plain HTTP messages which does not require changes on server side, as required for WebSockets . Plus it does not have requirement of allowing devices to be connected whole time with WebServer. Both serve different purpose, for continuous client and server communication use WebSockets, for receiving server updates using push technology use Server-Sent events. It is already supported in modern browser and no specific webinos implementation is required

Phase 2

"Web RTC": http://rtc-web.alvestrand.com/ Web RTC is still in a start-up phase and the goal is to define/select api?s, protocols and codecs that are required to enable real-time bi-directional communication in a web browser. Web RTC will enable the possibility to implement video/audio conference applications without installing plug-in components. The work with Web RTC will be divided between IETF and W3C/WHATWG. IETF will define/select the protocols and codecs whilst W3C/WHATWG will define the client API?s. The new client API?s will define the possibility to: 1. get user media from a camera or microphone (GetUserMedia API), 2. connect directly to a different peer (PeerConnection API) and 3. stream media and data between the peers (Stream API). As opposed to WebSockets, PeerConnection do not require that connections are relayed via a server. For example, two devices on the same IP sub network or with public ip addresses can connect directly to each other. To establish the connection the current working assumption is that ICE [RFC5245] will be used to negotiate and discover which addresses that can utilized to communicate directly between the peers. In some cases it is not possible to find a direct path between the peers depending on the network topology. In those cases a TURN server is used to relay the traffic between the peers. The working group has tried to agree upon a single session establishment protocol. SIP and XMPP have been proposed but it seems that the group will not agree upon one protocol. The current prediction is that the session protocol will be left out of the standard and initiatives will be started to create open source JavaScript implementations and let the market decide which implementation that will be used. Experimental implementations exists: https://labs.ericsson.com/developer-community/blog/beyond-html5-peer-peer-conversational-video http://my.opera.com/core/blog/2011/03/23/webcam-orientation-preview Web RTC does not replaces WebSockets. However, Web RTC is much better suited for exchanging data between peer with real-time characteristics. Work in W3C started in Web RTC WG. If the work is successful, implementations will most likely exists in all modern browsers before Webinos is ready. It might be provided in browser and no work might be required in webinos project

A common approach is to use either WebSockets or Server-Sent events and if fails use XMLHttpRequest.

Individual Components Communication

Description: To establish communication with server, which does not require continuous communication.
Requirement/architectural reference: ID-USR-Oxford-37 webinos SHALL provides methods to make applications addressable so that other applications can communicate with them.
Phase: Webinos Phase 1
Webinos responsible:

Candidate API Short Description Implementation Status Gaps Notes Decision
W3C XMLHttpRequest It allows performing HTTP client functionality directly from the script. It sends request directly to the WebServer without loading whole web page. Response are loaded without need to load the page, reply from server can be in XML, text, or in JSON format. Supported in all browsers Cross origin website access were used to be blocked but addressed via CORS It is ideal where communication is required between client and server but does require communication continuously such as submitting form. It is already supported in modern browser and there is no need of Webinos specific implementation

Messaging

Description: To send messages between application running on same device but with different instances.
Requirement/architectural reference: NM-DEV-FOKUS-001 It SHALL be possible to exchange information between multiple entities in terms of events.
DA-DEV-ISMB-003 Applications installed on a device SHALL be addressable, with multiple instances of the same application being separately addressable.
Phase: Webinos Phase 1
Webinos responsible:

Candidate API Short Description Implementation Status Gaps Notes Decision
W3C HTML5 Web Messaging (Referred as Channel Messaging in HTML5 Document) Two independent code that want to communicate directly. It supports port to port communication. Ideal for intra communication between two instances that run in different contexts. It is implemented in at least Chrome and Firefox as well in Android browser. For example test with http://www.html5test.com/ No caching support It is already supported in modern browser and there is no need of Webinos specific implementation

APIs for which no existing standards/implementations exist

Low level event handling API

Description: To send/receive/forward arbitrary data among any entity, in particular being suited for developing higher level APIs relying on data exchange featuring Webinos' overlay networking and discovery
Requirement/architectural reference: All NM requirements, WP 3.1 event handling draft architecture
Phase: 1
Webinos responsible/editor: Stefano D'Angelo/ISMB

High level Requirement Notes
Generating events
Sending/forwarding events
Registering/unregistering event listeners for incoming events

Application execution APIs

This section contains investigation results on application execution APIs.

Resources

Primary contributor/editor for this API category: VisionMobile
Supporting contributors/reviewers: Fraunhofer

Description

The Application Execution API allows activation of native and webinos applications installed on the device.

In addition, the API will support a facility for performing late run-time binding between different webinos applications. This facility is modeled after Intent mechanism of Android OS. An intent is an abstract description of an operation to be performed, which holds a passive data structure containing an abstract description of an action to be performed. For example webinos application may request the system to show a map using generic intent mechanism. The run-time will then choose which mapping application should be activated to perform the action. The requesting application is not required to have any knowledge of which specific mapping application is installed in the device.

Policies

Operation of Application Execution API is guided by Application Execution Policies, which can be modified by user. The policies control the following aspects of API operation:

Application Execution API provides mechanisms for webinos applications to discover current application execution policies, as well as test if specific webinos application is installed in the device, or is running in the device.

Analysis of requirements from WP2.2

The table below lists relevant requirements identified in WP2.2 and the compliance status based on current proposal.

Requirement Description Compliance Status Notes
DA-DEV-SEMC-004 Webinos SHALL provide means for an Application to detect the availability of a service. Phase 2 Postponed due to T3.5 decision to drop any policy querying API
DA-ASP-FHG-006 Webinos SHALL provide means to discover devices that have a specific application installed. Phase 2 Postponed due to T3.5 decision to drop any policy querying API
DA-DEV-ISMB-002 Applications installed on a device SHALL be discoverable, according to security policies. Phase 2 Postponed due to T3.5 decision to drop any policy querying API
NM-DEV-FOKUS-002 It SHALL be possible to subscribe to certain event types in order to get notified if the related event occurs. Phase 2
NM-USR-IBBT-002 It SHALL be possible to notify the user of application launch requests Phase 1
PS-USR-Oxford-112 The Webinos Runtime Environment SHALL be capable of specifying fine-grained security policies on all features of devices and user data. Phase 1
PS-USR-Oxford-37 Webinos SHALL allow access control decisions to be logged Phase 1
PS-USR-Oxford-38 Webinos SHALL allow policies which specify confirmation at runtime by a user when an access request decision is required Phase 1
PS-USR-Oxford-40 Users SHALL be able to modify policies about events before they occur (e.g. up-front policy specification) Phase 1
PS-USR-Oxford-49 User SHALL be able to view & manage application policies Phase 1
PS-USR-Oxford-52 Users SHALL be able to modify policies to allow or deny access to further functionality or data Phase 1
PS-USR-Oxford-75 The Webinos runtime SHALL be able to alert the user at runtime using a visual notification Phase 1
PS-USR_DEV-Oxford-46 Applications SHALL request for access rights to any device feature or policy-controlled item prior to accessing it. Applications MUST be able to continue to work in a limited manner if an access request to a feature is not granted. Phase 1
PS-USR-Oxford-62 Applications SHALL be isolated from each other. An application MUST NOT be able to view or modify another application's data or execution state Phase 1
LC-DWP-ISMB-116 Lifecycle operations regarding the Webinos runtime itself SHALL nicely integrate with the package management system of the underlying platform and SHALL follow platform-specific common practices. Phase 2
CAP-DEV-SEMC-202 It MUST be possible to register a background application for automatic execution at device start-up. Phase 2
CAP-DEV-SEMC-203 Webinos runtime MUST be able to start applications based on events, e.g. an incoming message, detected wifi coverage, sensor connected etc. Phase 2
CAP-DEV-SEMC-204 The webinos runtime SHALL be able to invoke applications by a timer based event. Phase 2

Functional API groups

The Application Execution API contains the following groups of functions:

  1. Activation of native app. Due to differences in security models between native and webinos apps, activation of native apps requires user consent. Optional completion code can be passed to the initiating webinos application.
  2. Activation of installable webinos apps. Activated application should be able to pass results to the originating application. The originating application shall be able to receive asynchronous notifications about completion of the activated application.
  3. Sending intents activating generic set of functions. There should be default handler and user selection of alternative handler.
  4. Inquire activation policies to discover current system configuration
  5. Test if specific webinos application is installed in the device
  6. Test if specific webinos application is running in the device
  7. Delivery of system-wide events (e.g. boot or shut-down, power-management) that start webinos app automatically whenever event occurs. This is similar to Android broadcast intents. (registration for the events is performed in webinos app manifest file.) This API is different from general event/messaging API, which is intended to be used to deliver information between two running apps. Broadcast event reception API is intended to deliver system-wide broadcast events, including starting an app that registered event, in case the app is not running.

The following table shows planned implementation status for Phase 1 and Phase 2.

API name Description Phase
Launch native Launch native apps installed on the device Phase 2
Launch webinos Launch webinos apps installed on the device Phase 1
Launch action Sending intents activating generic set of functions. Phase 2
Check policies Inquire activation policies to discover current system configuration. (Postponed due to T3.5 decision to drop any policy querying API (Berlin meeting)) Phase 2
Check local Test if specific webinos application is installed in the device Phase 1
Check running Test if specific webinos application is running in the device Phase 2
Broadcast event reception Delivery of system-wide events (e.g. boot or shut-down, power-management) that start webinos app automatically whenever event occurs. Phase 2

Phase 1 APIs

Webinos App Launcher API

Description: API for launching webinos applications installed in the device (local webinos apps)
Requirement/architectural reference:

Phase: 1
Webinos responsible: Michael Vakulenko, VisionMobile

Candidate API Short Description Implementation Status Gaps Notes Decision
BONDI 1.1 applauncher Module A JavaScript API that lists and launches applications installed on a mobile device. The apps are identified by URI with well-known MIME types. BONDI RI (reference implementation) Use of MIME types for identification of apps is different from webinos approach where apps are identified using application ID. Proposal: webinos API will be modelled after BONDI launcher API with necessary modifications to reflect webinos approach.

Check installed app API

Description: API for checking if specific webinos application is installed in the device

Requirement/architectural reference:

Phase: 1
Webinos responsible: Michael Vakulenko, VisionMobile

Candidate API Short Description Implementation Status Gaps Notes Decision
BONDI 1.1 applauncher Module A JavaScript API that lists and launches applications installed on a mobile device. The apps are identified by URI with well-known MIME types. BONDI RI (reference implementation) BONDI API allows to map apps to URI names discovering all registered apps. webinos will allow to check for presence of a specific webinos app. Proposal: webinos API will be modelled after BONDI launcher API with necessary modifications to reflect webinos approach.

Phase 2 APIs

Activation Policies API

Description: API for discovery of current policy setting

Requirement/architectural reference:

Phase: 2
Webinos responsible: Michael Vakulenko, VisionMobile

Candidate API Short Description Implementation Status Gaps Notes Decision
No suitable candidate identified This API may be folded into general policy control framework. The issue is discussed with T3.5. If decided otherwise, a new API will be specified for this functionality

Native App Launcher API

Description: API for launching native applications installed in the device
Requirement/architectural reference:

Phase: 2
Webinos responsible: Michael Vakulenko, VisionMobile

Webinos Intent API

Description: API for sending intents activating generic set of functions

Requirement/architectural reference: Need to clarify with T3.1

Phase: 2
Webinos responsible: Michael Vakulenko, VisionMobile

Candidate API Short Description Implementation Status Gaps Notes Decision
Web Introducer Web Introducer concept was initiated by Google. SEMC and Mozilla is cooperating with Google on the concept. The goal is to make the concept a W3C recommendation specification. Web Introducer enables web applications to discover a user's personal resources, no matter where they are hosted or produced, and gain permission to interact with them via a one-click user interaction. Currently there is an experimental pure HTML+JS implementation of the Web Introducer API that works in currently deployed modern browsers. Experimental applications are:
- Share Link
- Get image
TBD More detailed information about this API is available in Web Introducer investigation

Activation Test API

Description: API for checking if specific webinos application is running in the device

Requirement/architectural reference:

Phase: 2
Webinos responsible: Michael Vakulenko, VisionMobile

Broadcast event reception API

Description: API for reception of system-wide events. This API is different from general event/messaging API, which is intended to be used to deliver information between two running apps. Broadcast event reception API is intended to deliver system-wide broadcast events, including starting an app that registered event, in case the app is not running.

Requirement/architectural reference:

Phase: 2
Webinos responsible: Michael Vakulenko, VisionMobile

Supporting information

Candidate API Short Description Implementation Status Gaps Notes Decision
WAC 2.0 Device APIs: Web Standards/ 2.8. URI Schemes URI schemes are the defined method for WAC applications to launch other applications. Specification is Proposed Released Version Just local apps. The system defines which application is started depending on scheme or file type. E.g. <a href="tel:+123">dial</a> would start the dialer or <a href="data:application/pdf:...>open</a> would open the pdf data.
W3C DAP The Application Launcher API A JavaScript API for launching native applicatinos on a device. W3C ED Just local apps. Current Editor's Draft allows to query installed applications and set default applications. So you can either let the system decide which app to start or explicitly start an application. But multiple members of DAP want just URI schemes, few voices suggest a module is needed for mobile (See minutes and current charter). Note by Claes 20110331: According to DAP phone meeting 2011-03-30 there is a decision to not include the App Launcher in the charter.
Mozilla Open Web Apps JavaScript API Open Web Apps from Mozilla is a spec that can package a website and make it installable in the browser. The JavaScript API handles installation and management functions. Experimental Firefox 4 add-on
Experimental Google Chrome extension
Besides listing and launching applications, installing and uninstalling other applications is also supported.
BONDI 1.1 applauncher Module A JavaScript API that lists and launches native applications on a mobile device. BONDI RI (reference implementation) Just local apps. Doesn't support setting default applications. Application can be explicitly started. E.g. bondi.applauncher.launchApplication(succCallB, errCallB, "file:/bin/fpsgame");

Background tasks

Description: To run task in background. This is an independent entity and result of worker thread is updated to event.
Requirement/architectural reference: CAP-DEV-FHG-200 The webinos runtime SHALL be able to run applications in the background.
Phase:
Webinos responsible:

Candidate API Short Description Implementation Status Gaps Notes Decision
W3C Web Workers Web Workers instantiate scripts which run in parallel and does not require any input from UI or script handling page. To handle I/O operation it can make use of XMLHttpRequest to get output. Results of Worker thread are updated to the subscribed event. Implementation of Web Workers is present in all browsers, some have basic functionality and some support shared worker functionality None identified, except it has quite high performance startup time and high memory consumption. Web workers are intended to facilitate multi-threading in web apps. This is good for background tasks that do not require to update the DOM tree/UI directly. However, web workers are not feasible for background jobs that needs to be started at system start up etc.

Discovery APIs

Description

This section contains investigation results on APIs for device and service discovery.

Resources

Primary contributor/editor for this API category: Samsung
Supporting contributors/reviewers: Fraunhofer / SEMC / T-Systems / W3C

Overview of Discovery Technologies

Each interconnect technology can have its own discovery mechanisms, and some have several, each with their own terminology. Webinos will need to provide an overlay that abstracts away from the variations and which offers simple naming for end users and web developers. The overlay will need to store the mapping from user friendly names to the underlying data registered for the device and needed to communicate with it.

Interconnect technologies include:

Only some of these support IP directly. Webinos should provide a means for an IP accessible device to proxy for devices that are not IP addressable.

IP based networks

For IP based networks, three such mechanisms are:

Multicast DNS

Invented by Apple for simplifying the connection of devices in home networks. The Apple implementation is called "Bonjour". An open source equivalent is "Avahi". Devices start by randomly picking a link local IP address in the range (169.254.*.*) and making an ARP request to see if this address is already in use.

Devices assign themselves name in the ".local" domain, and will adjust this if they detect other devices with the same name. Users can assign human meaningful names with spaces in them. User agents query for devices with multicast UDP requests. The devices check for a match and respond with a multicast UDP packet with the IP address and port number, the device's domain name, and a list of protocol and/or service names. The device domain names use human meaningful conventions e.g. "Dave's laptop._workstation.local". A nice feature is the ability for a device to report on other devices including external services such as the BBC news on the Web, or a hotel's local Web server giving details of the hotel's services. Multicast DNS isn't designed to support tens of thousands of devices, but this can be worked around with discovery hubs.

More information:

On Linux, try

mdns-scan

or

avahi-browse -a -v

This only found my Linux workstation on my WiFi network and not the ADSL Modem, nor the Samsung laser printer.

Simple Service Discovery Protocol (SSDP)

Invented by Microsoft and considerably more complicated than Multicast DNS. SSDP is a UPnP-based protocol and it uses HTTP for notification announcements that give a service type URI and a unique service name.

On linux try

gssdp-device-sniffer

On my WiFi network this found the ADSL Modem and the Laser printer, but not the Linux workstations.

Service Location Protocol (SLP)

Defined in RFC 2608 and supported by Hewlett-Packard's network printers, Novell, and Sun Microsystems, but ignored by some other large vendors. SLP works over UDP or TCP. On UDP, devices listen on port 427 for multicast requests. Devices advertise themselves with a URI like

service:printer:lpr://myprinter/myqueue

This may be supplemented by a list of attributes, e.g.

 (printer-name=Hugo),
 (printer-natural-language-configured=en-us),
 (printer-location=In my home office),
 (printer-document-format-supported=application/postscript),
 (printer-color-supported=false),
 (printer-compression-supported=deflate, gzip)

If the data doesn't fit in a single packet, a flag is given that the user agent can act on to request the SLP info via TCP. SLP also supports discovery agents and presumably this helps with scaling up to larger networks with bridged local networks.

UPnP and DLNA

On linux try

upnp-inspector

On my network this found the ADSL Modem but not my Laser printer.

Other interconnect technologies

WiFi

For WiFi it is possible to detect access points and what kind of encryption they are using, if any, as well as devices operating in ad-hoc mode. It should be possible to detect device MAC addresses.

USB

For USB see the source code for the Linux lsusb command. This lists the bus and device number, the device ID and a human readable description e.g. Logic3 / SpectraVideo plc A4Tech SWOP-3 Mouse, and Microdia Sonix Integrated Webcam.

Bluetooth

For Bluetooth, a scan shows the device ID and type, e.g. phone. This id can be used as a proxy identifier for people, i.e. who is present in the room or nearby. There is a small set of known device types, e.g. phone, input device, headset, modem, computer, network, camera, printer or video device. Users can provide a meaningful name for their device e.g. "Me" as seen for a phone in a car that drove past my window!

APIs based on existing standards/implementations

Low level Service Advertising APIs

Description: Service to advertise its availability and capabilities APIs

Requirement/architectural reference:

Phase: Webinos phase 1
Webinos responsible: Ziran/Samsung
Candidate API Short Description Implementation Status Gaps Notes Decision
Avahi Register Services API based on DNS-SD It uses DNS service locator (SRV), Text Record(TXT), and Pointer recorder (PTR) records to advertise Service Instance Names. The hosts offering services publish details of available services: instance, service type, domain name and optional configuration parameters. In case of mDNS, each computer on the LAN stores its own list of DNS resource records (e.g., A, MX, SRV) and joins the mDNS multicast group. If a unicast DNS is available, two ways to advertise services: via dynamic DNS server or manually add DNS records to describing the services to add. Avahi had already become the de-facto standard implementation of mDNS/DNS-SD on free operating systems such as Linux. Native Codes. It suits Local or wide-area network with the same domain. This is low level API - one option is to wrap native code and expose as JavaScript Object method - here is an example To be considered for phase 2
Strophe.js API for XEP-0124 BOSH Strophe.js provides Javascript library for BOSH implementation, which enable XMPP over HTTP. For service advertisement, XEP-0060 Publish-subscribe APIs shall be implemenated on the top the existing Strophe.js library. XEP-0060 Publish-subscribe specifies that an entity publishes information to a node at a publish-subscribe service. The pubsub service pushes an event notification to all entities that are authorized to learn about the published information. Strophe.js is well used. It has been tested on Firefox 1.5, 2.x, and 3.x, IE 6, 7, and 8, Safari, Safari Mobile, Google Chrome, and it should also work on the mobile Opera browser as well as the desktop Opera browser. Strophe.js does not needs particular support for specific XEP. Expanding XEP-0060 implementation based on Strophe.js should be straightforward No API will be developed by WP3.2 as a downloadable JS library is available

Low level Find Service API

Description: Allows applications to find services based on description

Requirement/architectural reference: Phase: Webinos phase 1
Webinos responsible: Ziran/Samsung
Candidate API Short Description Implementation Status Gaps Notes Decision
Avahi Browse Services API based on DNS-SD To browse for available services. In case of mDNS, Updates about the new service availability is done by sending the multicast advertisement same as advertisement same as advertisement To be considered for phase 2
Strophe.js API for XEP-0124 BOSH" To find service, XEP-0030: Service discovery API shall be implemented on the top of Strophe.js. XEP-0030 specifies discovering service via JID. (1) the identity and capabilities of an entity, including the protocols and features it supports; and (2) the items associated with an entity, such as the list of rooms hosted at a multi-user chat service. Strophe.js has been tested on most well-used browsers (see above). Strophe.js does not needs particular support for specific XEP. To implement discovery over BOSH, simply send IQ-get stanzas to the server with a certain namespace. No API will be developed by WP3.2 as a downloadable JS library is available

APIs for which no existing standards/implementations exist

High level Discovery API

Description

Currently there exist several methods to do service discovery. This has been explored in the state of the art investigation for service discovery. Some of these methods are fairly well deployed and used such as Bluetooth service discovery, Universal Plug & Play, mDNS or DNS Service Discovery. However, neither of these discovery methods has been exposed to web application developers. In addition methods like Universal Plug & Play, mDNS and DNS SD do not have any robust security model.

The goal with the webinos high level service discovery API is to be able to provide a simple API for application developers. The API shall provide the means to discovery services within personal zones and from low level service discovery methods supported by the device. The fact webinos uses a overlaying network, service discovery will not be limited to local services but will also enable to discover remote services. The API hides the complexity for communicating with services residing in a different peer in a trusted manner.

Requirement/architectural reference

The following 2.2 requirements are applicable for the high level Discovery API.

Phase: Webinos phase 1

Phase: Webinos phase 2

Webinos responsible/editor: Anders Isberg / SEMC

Security and Privacy APIs

Description

This section contains an overview of the required APIs for the webinos security architecture and background information about related work.

Resources

Primary contributor/editor for this API category: Oxford
Supporting contributors/reviewers: Polito, DOCOMO

Aims for Security and Privacy APIs

The following requirements must be satisfied:

However, the first two of these requirements have been moved to phase 2 of the implementation as the security architecture is further clarified.

In addition, various requirements (PS-USR-Oxford-103, PS-USR-Oxford-26) require users to authenticate through device-specific capabilities. Therefore, an authentication API has been specified.

Aims for Security and Privacy APIs in phase 2

The following proposals will be investigated in phase 2 of the webinos platform:

Existing standards

The following APIs for security (e.g. cryptography and authentication) and for attestation exist.

APIs for which no existing standards/implementations exist

Attestation API

Description: The purpose of this API is to provide a secure means to query the device to find out the identity and integrity of running software. The example use case is Trusted Computing Mobile Reference Architecture . However, this is aimed at a lower layer than webinos. The aim of the attestation API is simply to allow access to existing functionality.
Requirement/architectural reference: ID-DEV-POLITO-005, ID-DEV-POLITO-006, ID-DEV-POLITO-007, ID-DEV-POLITO-008
Phase: 1
Webinos responsible/editor: John Lyle
High level Requirement Notes
This API shall be capable of exposing basic TCG attestation capabilities
This API shall not rely upon a specific hardware implementation
This API shall provide applications with the ability to fetch authenticated data about the runtime state of the platform

Authentication API

Description: Provides information to applications about the current authentication status of users, as well as allowing applications to request re-authentication..
Requirement/architectural reference: PS-USR-Oxford-103, PS-USR-Oxford-26
Phase: 1
Webinos responsible/editor: John Lyle
High level Requirement Notes
This API shall allow applications to request that the user authenticate to the device
This API shall allow applications to find out when and how the user last authenticated
This API shall not expose identity information about the user

User profile and context APIs

Description

This section contains investigation results on user profile APIs and context APIs.

The user profile API defines attributes and methods to access to user related information (e.g. name, nickname, gender birthday, etc.) while the application data API provide information about application related information (e.g. installed application).

Resources

Primary contributor/editor for this API category: T-Systems
Supporting contributors/reviewers: DoCoMo, NTUA

Analysis of requirements from WP2.2

The table below lists relevant requirements identified in WP2.2 and the compliance status based on current proposal.

Requirement Description Compliance Status Notes
CAP-DEV-SEMC-010 webinos SHALL provide means for applications to access user?s profile data. Phase 1
CAP-DEV-SEMC-011 webinos SHALL provide means for applications to access user?s preference data Phase 2 An secure and optimal method to store user preferences must be found to provide privacy aspects and avoid a blow up of user preferences (e.g. different applications would like to store the same information in the user preferences -> ColorBlind:RedGreen is the same as ColorBlind:GreenRed).
ID-USR-POLITO-100 webinos components that have to be shared or referenced (device, application, data, user) SHALL be identifiable. Phase 1 The user profile has a unique id.
DA-DEV-ambiesense-040 It MUST be possible for applications to share context information across devices, so that for instance social context can be updated when friends enter/ leave the same situation. Phase 2 In phase 1 the user profile API implements social contact information. Further contextual information must be evaluated for phase 2.
PS-DEV-Oxford-86 The webinos runtime SHALL support the confidential storage of user credentials including usernames and passwords. Phase 2 A secure method to store login credentials must be evaluated for phase 2.
PS-USR-IBBT-005 The webinos system SHOULD store associations between device, user and context information securely and provide this information based on user preferences. Phase 2 Same as CAP-DEV-SEMC-011.
PS-USR-VisionMobile-10 webinos SHALL allow users to express their privacy preferences in a consistent way. Phase 2 Same as CAP-DEV-SEMC-011.
PS-USR-VisionMobile-11 webinos applications SHALL be able to query the webinos user privacy preferences. Phase 2 Same as CAP-DEV-SEMC-011.
NC-DEV-IBBT-0015 Applications MUST be able to access the user's general webinos preferences (with the permission of the user). Phase 2 Same as CAP-DEV-SEMC-011.

Phase 1 APIs

APIs for which no existing standards/implementations exist

User Profile API

Description: User Information
*Requirement/architectural reference:

Phase: Webinos phase 1
Webinos responsible: Ronny Gräfe / George Gionis
Candidate API Short Description Implementation Status Gaps Notes Decision
W3C Contacts API Contacts provides a basic list of information about a person, but is insufficient for webinos needs. Contacts provide only 'real life' information about a user, but no technical information (like preferences). It also doesn't allow granularity of access. And has no specific API for the user (as opposed to other contacts). Decision was made to build own API for webinos, based on elements from Contact and Portable Contacts. See note below table.
Portable Contacts The reference presented by George Gionis added account information for user accounts for external social network profiles, which is useful for context awareness and calculation of social proximity. We can base user profile information on the account information suggested by portable contacts.. Decision was made to build own API for webinos, based on elements from Contact and Portable Contacts. See note below table.

The data accessible through the API for user profiles will be based on the W3C contacts information with additional information for social network profiles based on Portable Contacts.

Phase 2 APIs

User Profile API

Description: User Information
*Requirement/architectural reference:

Phase: Webinos phase 2
Webinos responsible: ?
Candidate API Short Description Implementation Status Gaps Notes Decision
No suitable API identified