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.
This section contains investigation results on APIs for access to HW related resources.
Primary contributor/editor for this API category: Telecom Italia
Supporting contributors/reviewers: SEMC / AmbiSense / Fraunhofer / BMW
| 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. |
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 |
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 |
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>
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 |
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. |
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.
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 |
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 |
| 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.
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.
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: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| 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 |
This section contains investigation results on APIs for access to application data.
Primary contributor/editor for this API category: Fraunhofer
Supporting contributors/reviewers: SEMC / W3C
See W3C current state of mobile web app technologies: data storage as a good starting point.
| 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.
| 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.
| 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.
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 |
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:
| 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.
| 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.
This section contains investigation results on APIs for communication with other devices, other applications and servers.
Primary contributor/editor for this API category: Samsung
Supporting contributors/reviewers: SEMC / ISMB / VisionMobile
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.
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 |
| "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.
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 |
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 |
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 |
This section contains investigation results on application execution APIs.
Primary contributor/editor for this API category: VisionMobile
Supporting contributors/reviewers: Fraunhofer
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.
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.
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 |
The Application Execution API contains the following groups of functions:
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 |
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. |
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. |
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 |
Description: API for launching native applications installed in the device
Requirement/architectural reference:
Phase: 2
Webinos responsible: Michael Vakulenko, VisionMobile
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 |
Description: API for checking if specific webinos application is running in the device
Requirement/architectural reference:
Phase: 2
Webinos responsible: Michael Vakulenko, VisionMobile
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
| 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"); |
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. |
This section contains investigation results on APIs for device and service discovery.
Primary contributor/editor for this API category: Samsung
Supporting contributors/reviewers: Fraunhofer / SEMC / T-Systems / W3C
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.
For IP based networks, three such mechanisms are:
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-scanor
avahi-browse -a -vThis only found my Linux workstation on my WiFi network and not the ADSL Modem, nor the Samsung laser printer.
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-snifferOn my WiFi network this found the ADSL Modem and the Laser printer, but not the Linux workstations.
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/myqueueThis 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.
On linux try
upnp-inspectorOn my network this found the ADSL Modem but not my Laser printer.
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.
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.
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!
Description: Service to advertise its availability and capabilities APIs
Requirement/architectural reference:
| 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 |
Description: Allows applications to find services based on description
Requirement/architectural reference:| 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 |
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
This section contains an overview of the required APIs for the webinos security architecture and background information about related work.
Primary contributor/editor for this API category: Oxford
Supporting contributors/reviewers: Polito, DOCOMO
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.
The following proposals will be investigated in phase 2 of the webinos platform:
The following APIs for security (e.g. cryptography and authentication) and for attestation exist.
| 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 |
| 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 |
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).
Primary contributor/editor for this API category: T-Systems
Supporting contributors/reviewers: DoCoMo, NTUA
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. |
Description: User Information
*Requirement/architectural reference:
| 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.
Description: User Information
*Requirement/architectural reference:
| Candidate API | Short Description | Implementation Status | Gaps | Notes | Decision |
| No suitable API identified |