BONDI 1.1 (Approved Release) Release Notes (09/01/10) ======================================================= The BONDI 1.1 release define the composite specifications to allow web applications (widget and web pages) to interoperate over BONDI defined execution environment (widget runtime and web user agent). BONDI technology enables web based content to access native device capability, intermediated through a robust, but flexible security framework. There are three elements to the 1.1 release - APIs: defines the JavaScript functions that expose the underlying accessible device capability - Architecture and Security Specifications: defines the security layer and required architectural components that insulate the web application against risk - Compliance: define the compliance process that allows a widget runtime or web user agent to declare compliance against the BONDI specifications The BONDI 1.1 Approved Relase release differs from the 1.0 release in the following important ways APIs ---- - API features are now versioned to help with backward compatibility issues and to future proof the design. This versioning also ensures consistency with the APIs and the underlying security model. - Messaging module has been redesigned to absorb functionality previously present in commlog. This is based upon feedback from developers and anticipates the introduction of the telephony API in version 1.5. - Device capabilities have been significantly simplified. Device capabilities directly interact with the security model and also impact UI behavior and API design, based on the premise that APIs that issues potential security prompts should be asynchronous. This simplification is based upon implementation experience - Filtering pattern has been considerably improved and applied consistently across all modules . This is intended to improve the developer experience and to optimize the handling of larger data structures. - Camera API has been enhanced to handle of the embedded and native camera applications. - Telephony module replaced commlog module and itself is a candidate for update in BONDI 1.5 - PIM Modules: The access to the properties has been simplified by accessing directly the interfaces attributes. The data model for contacts, calendars and events has been also improved. - The write capability has been removed from Device Status API. - The following APIs have grouped all their security features in a single one per API: DeviceStatus and Gallery. Architecture and Security ------------------------- - Four new features have been added to provide the ability to disable specific widgets to defend better against the risk of malicious and Trojan widgets. These new features allow the security policy to intercept and apply appropriate rules at the point of widget installation, un-installation, update and instantiation. - http://bondi.omtp.org/lifecyle/widget-install - http://bondi.omtp.org/lifecyle/widget-instantiate - http://bondi.omtp.org/lifecyle/widget-update - http://bondi.omtp.org/lifecyle/widget-uninstall - Revision to the requirements relating to user prompts, to be more compatible with non-modal (ie non-blocking) prompts. - Addition of the bondi.getFeatures() API, to allow application code to be notified of the availability of Features within the current context. - Addition of the PendingOperation.wait() API, to allow application or framework code to wait for the completion of an asynchronous operation. Compliance ---------- Compliance Process - What BONDI Compliance is not? section - added - Submission section - added - What is BONDI compliance section - updated - Links and references in line with 1.1AR release - updated - Submission email address - added Compliance Matrix - Updated in line with 1.1AR changes (requirements and links: test etc.) - Summary sheet and class support entry - included - Auto-populate based on classes - supported - Logic and usability - improved Compliance Coverage Status - a new document has been added which gives a precise snapshot indicating which parts of BONDI functionaltiy are supported by objective repeatable Javascript tests - this is work in progress and will continue to evolve HISTORY:: BONDI 1.1 (Candidate Release) Release Notes (26/10/09 ====================================================== The BONDI 1.1 release define the composite specifications to allow web applications (widget and web pages) to interoperate over BONDI defined execution environment (widget runtime and web user agent). BONDI technology enables web based content to access native device capability, intermediated through a robust, but flexible security framework. There are three elements to the 1.1 release - APIs: defines the JavaScript functions that expose the underlying accessible device capability - Architecture and Security Specifications: defines the security layer and required architectural components that insulate the web application against risk - Compliance: define the compliance process that allows a widget runtime or web user agent to declare compliance against the BONDI specifications The BONDI 1.1 candidate release differs from the 1.0 release in the following important ways APIs ---- - Messaging Events are supported. - Binary Messaging Support. - Detailed and consistent filtering of PIM info and comm logs. - Maps replaced with specific data types. - More attributes for PIM elements and messaging. - UI Settings management added. - Camera API redesigned. Architecture and Security ------------------------- - Widgets use of requestFeature(). - Features, sub-features, aggregate Features, and associated clarification of requestFeature() - Minor clarification to processing of multi-valued attributes in the definition of the policy model in A&S appendices - IRI vs URI changes - Improving use and consistency of terminology for "launch" "invoke" "instantiate" etc with respect to Widgets. - B.4.1 Widget Subject Identity issues - Network access features - Updates to W3C document references - Change Definitions and perhaps other sections to be normative. - flat structure of Web IDL - “module” statement has no semantics in BONDI - “implements” Web IDL keyword is used to define the hierarchy of instantiations - “\def-instantiated” keyword in widl is used to specify upon which feature the interface may be instantiated - Feature-sets are used to group features - New device capabilities - messaging.binary.send - messaging.mms.subscribe - messaging.sms.subscribe - messaging.binary.subscribe - ui Compliance ---------- - Process document - Compliance process document amended - Compliance Matrix - Deleted the empty Policy & Widget Examples spreadsheets. - Deleted Device Capabilities List in the Security Policy Language spreadsheet - Re-formatting to HTML in progress - Fixes have been applied to requirement numbering and cross referencing - Improvements the test coverage have been made