Introduction

What is the Rich Web Application Backplane?

• Common building blocks underlying web application design
  • Common sets of events
  • Common approach to data submission
  • Common set of DOM interfaces
  • Common approach to accessibility

But what about

• Distributed Web applications and remote eventing
• Dynamic access to local and remote resources
• Trust, identity, privacy and security
• Saving bandwidth and battery life for common components
• Base URI for script libraries?
• Bookmarks and browser history for Rich Web Applications

First a quick look at the proposed Ubiquitous Web Applications WG

Ubiquitous Web Applications Working Group

• Mission

  To simplify the creation of distributed applications involving a wide diversity of devices through the application of Web technologies such as markup and event-driven scripts.

  Web of Everything Incorporates a very wide range of devices Physical world of sensors and effectors Access to local and remote capabilities Autonomous agents that act upon behalf of their users

• Success will mean
  • The availability of a framework for authoring distributed Web applications that minimizes the costs for dealing with a wide diversity of devices
  • The ability of mainstream Web developers to create distributed applications through the use of markup and scripting, where local and remote services are exposed as DOM objects
  • Attention to the trust, identity, security and privacy issues as needed to enable widespread use of such applications

Ubiquitous Web Applications Working Group

Successor to Device Independence WG

• Concrete short term work items with workshops to set longer term directions
• Complete and extend existing DIWG work items on DIAL, DISelect, DCI and CC/PP
• Study and make proposals for advanced markup languages for declarative models of distributed Web applications at a level above that of individual Web pages, and including client and server components, starting with a workshop in early 2007
• Develop proposals for remote eventing, device coordination, and safe and secure access to device capabilities, including physical sensors and effectors
• Study and make proposals for autonomous Web agents that act on behalf of, and are controlled by users, starting with a workshop in early 2008

Declarative Solutions for Device Diversity

• Applications models that extend across web pages, and embrace both clients and servers
• Policies that can be used to assemble the content, media, scripting and styling resources to satisfy the goals as appropriate to the delivery context
• Building upon industry experience with proprietary frameworks, and exploiting SCXML to leverage the proven capabilities of UML

Distributed Applications

• May involve several devices
  • Handheld controller
  • Wall screen (an evolved TV)
  • Printer
  • Media Server
  • Web site for program guide
• May involve several users
  • Remote meetings
• Server-based Interaction Manager
• Modality components
  • Visual, aural, tactile interfaces
  • May be composed of distributed subcomponents
• Sensors and effectors
• RFID tags and 2D Bar-codes
  • Avoiding the need to type URIs/IDN's

Device Coordination

• Dynamic access to local and remote resources
• DCI as framework for user preferences, device capabilities and environmental conditions
  • As a hierarchy of DOM nodes that may raise events to notify changes
  • These nodes may support additional interfaces for specific capabilities
• DOM interface for binding to resource
  • By name, description or link to description
  • Can link to web server for binding service
  • Bound resource is exposed as DOM object
  • Events signalling binding, unbinding, and errors
  • May be layered on existing service, e.g. UPnP
• Bound object exposed through DCI
• Work on defining ontologies of services
  • In cooperation with OMA and DLNA

DOM Proxies and Remote Eventing

• DOM Objects as proxies for local or remote resources
• Developers are shielded from protocol or API details
• Events are propagated between remote DOMs

Remote Events

• REX - Remote Events for XML
  • Extensible XML grammar for event transport
  • Independent of transport medium
  • Supports remote event listeners and remote event dispatch
• Enabling Web apps to listen to remote event sources
  • Subscribe/Notify model isn't sufficient
  • Firewalls and NAT present major challenge
  • Continuous TCP connection drains battery
  • Thus use of proxies on public Internet
• Turns Web applications into agents that listen to requests and act on user's behalf
  • Autonomous agents could be based upon SCXML
  • Running on local device or on large website

    

Trust, identity, privacy and security

• When is it okay to give a web page permission to
  • access your calendar, contacts and messages
  • access your current location
  • access your photos, videos, and music, etc.
  • access your device's microphone or camera
  • send messages on your behalf, perhaps to a different website
• What if the web page changes in some way?
  • assuming you granted permission on previous occasion
  • checksums can be used to detect changes
  • but some changes may be okay, e.g. versioning
  • page could be signed by someone you trust
  • study needed on use cases and requirements
• Identity and Privacy
  • identity of web pages, individual users, devices and groups
  • managed approach to privacy with limited disclosure
• Good topics for upcoming workshop

Saving Bandwidth and Battery Life

• Rich Web applications use lots of modular scripts
• Each website provides its own copy of these libraries
• This is wasteful of bandwidth and battery life for mobile devices
• Need a way to enable smarter caches
  • may already have cached copy from another website
• location independent object identifiers
  • cryptographic checksum passed as an additional attribute or as part of document metadata
  • HTTP digest and want-digest headers, see RFC3230
  • applicable to scripts, markup (XBL, XUL, SVG), graphics, sound effects, style sheets, etc.
  • similar issues as on previous slide for changeable resources
• Impacts security mechanisms

Base URI for script libraries?

• Rich Web applications often use scripts to generate user interface controls
  • This involves loading images and other resources
  • These form part of a library that may be used by many pages
• Relative URIs are resolved relative to the Base URI
• For XHTML and CSS the Base URI is the URI used to load the markup or stylesheet
• For scripts, the Base URI is inherited from the markup document that loaded the scripts
• This causes problems for loading resources within scripts
  • Updating the script when library is moved to another website
  • Prevents access to resource for offline usage
• A backwards compatible solution is needed!
  • Exacerbated by lack of modules in ECMASCript 3rd edition, but 4th edition (JavaScript 2) may help

Bookmarks and Browser History

• Rich Web applications introduce states that by default aren't reflected in the browser history and which can't be bookmarked
• HTML Slidy as informative example
  • Renders div elements as a sequence of slides
  • Makes use of fragment identifier to enable bookmarks to individual slides and to support slide to slide links
    • This slide is http://www.w3.org/2006/Talks/1120-dsr-uwa/#(13)
  • But lack of effective cross-browser API for managing history of slide transitions
  • As a result, Back and Forward actions don't work as user expects
• Need cross-browser standard for Rich Web Applications to manipulate history
• Privacy concerns should limit this to states introduced by the Rich Web Application