TPAC/2012/smarterwebapps

From W3C Wiki
< TPAC‎ | 2012
(Redirected from TPAC2012/smarterwebapps)

Attendees are encouraged to add/modify the proposed agenda items below. Being a potentially broad subject, suggestions for narrowing the agenda by assigning priorities to the following topics or otherwise are also welcome.

Results of the session, and next steps

One of the key discussion points was whether ability of apps to know the current connection state (and type), and what developers could do with that info e.g. enabling the app to make network usage decisions at its level. The comments can be summarized:

    • enabling apps to make connection management decisions directly may conflict with similar efforts by the user agent (e.g. browser) or a lower-layer connection management service on the device.
    • this need is an indication that "we have failed to stitch the OS and web platforms together properly"
    • enabling apps to express their network usage needs/preferences (rather than control connection state directly) would be beneficial, if there was something underneath (e.g. UA or OS) that could address those needs
    • in the absence of lower-layer support, we still have the need to optimize resource usage at the app layer if possible, so context awareness is still important
    • if users can set preferences at the OS layer (e.g. for data usage when roaming, or retrieval of large content only over WiFi/unmetered connections), then those preferences need to be exposed to the UA at least
    • exposing network info to apps is a privacy risk (this echoes a significant amount of discussion in the Device API WG on this issue), and the OS should be in a better position to address the needs
    • if not addressed by W3C there will likely be other efforts to expose this info to apps nonetheless, either through
      • device-based approaches, e.g. the OMA Open Connection Management API
      • network-based approaches, e.g. network APIs which determine the access network type from DNS info or IP address ranges
    • both users and service providers (e.g. network operator) may be involved in setting preferences and policies; the connection management service on the device (if there is one) is responsible for mediating between those preferences, policies, and the needs of apps (which thus need some form of expression)

The Network-Friendly App and WebApp Best Practices Community Group will capture the rest of the ideas in the two presentations, and provides a forum for further followup. Privacy discussions related to network context awareness are expected to continue in the Device API WG, and will also be summarized on the CG wiki.

Notes on this outline and goals of the session

    • Address how the GSMA's Smarter Apps guidelines can apply to the Web, and what is needed beyond what is currently supported
      • Some of “what you can do” below are just ideas and need validation
    • Provide code examples and references where they exist
    • Highlight specific projects that will add value as standards development (APIs), best practices, open-source libraries, etc
    • Collect input from attendees on all the above

Outline

Smarter Webapps for Smarter Phones

    • The GSMA's “Smarter Apps for Smarter Phones” primarily focused on native app development and platform APIs
    • But many of the same objectives and general techniques also can apply (or will someday be applicable) to the Web
    • This session will address how some of those objectives may be achievable using today's Web standards, and beyond
      • what you can do, today
      • what more do you need, either as known gaps of the Web in supporting the smarter app objectives, or other things we haven’t considered yet

What you can do today: UX focus

    • Asynchronous operation, user-centric UI
      • Manage data delivery in background threads
      • Keep the user informed of state as needed
    • Online awareness, e.g. via navigator.onLine and the DAP Network Information API

What you can do today: efficiency focus

    • Online awareness and opportunistic content delivery
    • Request timing for efficient radio use & radio resource control (RRC) signaling
      • What we know
        • Dedicated->FACH transition takes ~8 seconds
        • FACH takes ~1/3 power of Dedicated; can support up to 70 bytes per TCP packet
        • FACH->Idle takes ~8 seconds; reconnection takes ~1-2 seconds
      • Tools such as AT&T's freely-available Application Resource Optimizer (ARO) can show network usage and related RRC events, and can be used to identify where app design changes can improve network usage
      • "Secondary requests" etc could be queued & bundled
      • Apps could be allowed to specify a max latency
    • Use dedicated, FACH-compatible Push (SSE, WebSockets)
      • Rather than HTTP polling or long-polling
        • Is HTTP long polling less efficient than SSE or WebSockets?
          • SSE is based on automatic repetition of HTTP long polling
          • WebSocket requires much less length of headers and TCP reconnections than those of HTTP, while WebSocket may keep its TCP connection for much longer time
      • Need: guides for server implementation of SSE/WebSockets
    • Randomize request scheduling
      • Queue requests, allowing for max variation in schedule or delay
      • For periodic or event-driven requests, not user-invoked
    • Cooperative request scheduling
      • Use a shared worker as a request manager for multiple threads
    • Opportunistic data caching
      • Use cache controls and byte range download with XHR
      • Use IndexedDB with easy-to-use Filesystem APIs e.g. idb.filesystem.js
      • Use a local/shared service for cache management, e.g. via Web Intents, e.g. the Pick Media Intent
    • Media transcoding
      • Scale down photos prior to upload when desirable (e.g. no degradation of UX)
    • Compression
      • Use HTTP compression
      • Need: guide for configuration of HTTP compression, when to use it and when not to
    • Optimize content and JavaScript
      • Use APIs to deliver only needed content
      • Use minimizers for JavaScript
    • Focus / viewmode awareness
      • Use window events to avoid needless UI operations
    • Optimize data transfer cost/value
      • Build-in content/feature usage metrics

Network awareness in a multiple-network environment

Proposed by: Hidetoshi Yokota

PowerPoint Slides

Smartphones nowadays have multiple network interfaces like 3G, LTE and WiFi and Smarter Webapps should have a smarter way to use those networks in order to improve UX. Better awareness of the network interface will help select an appropriate network based on its condition or data type/volume.

Proposed approaches to be discussed are two folds:

  1. Web API to retrieve more detailed information on the network interface(s) for more efficient network usage
    • Network information obtained solely by the terminal (e.g., Cellular and WiFi base stations, signal strength, error rate, throughput),
    • Network information obtained by cooperating with the network (e.g. access network load, backhaul load, congested APs) via 3GPP ANDSF or WFA Hotspot 2.0.
  2. Web API to control network interfaces for fine-grained network selection
    • Network interface control should support not only open/close, but also attachment to a specific base station in WiFi network, establishment of a dedicated bearer in cellular network, etc.
    • Support of concurrent usage of multiple networks and access network selection based on the content type (video/voice/text) .

The objective of the discussion is to share the current issues in the mobile network and explore potential solutions and requirements. The future goal is to define new or enhanced APIs for web applications to provide above capabilities in appropriate WGs.

What more do you need?

    • Adaptive streaming
      • Any other topic except HLS or the HTML Media Source Extensions?
      • JavaScript libraries enabling effective use of adaptive streaming manifests, and network performance info
    • Roaming awareness
      • Extension to the DAP Network Information API, and/or new API spec (e.g. Network Interface API, which will be the SysApps spec)
    • Tariff awareness
    • Shared Push systems
      • e.g. accessed via the Push API being developed in Webapps
    • Shared (multi-app) cooperative request handling and caching
      • Can this be delegated to a Web Intent provider, to address same-origin limitations in IndexedDB?
    • Virtual filesystem for text and binary content
    • Guidelines as to what techniques will help the most for different "app types". e.g. per Facebook's assessment of the "Mobile Web App Profile"

What Should W3C Do as Next Steps

    • Socialize what is needed and determine where to do it
      • Determine how much of “what you can do” is really feasible, and recommendations/guidelines on how to do it
      • For “what is needed”, prioritize and find a home in W3C
    • For example, in the Web Performance WG, perhaps
      • Support for network-related parameters
      • Best practices for tuning network usage and UX effectiveness

Other ideas

    • feel free to add/edit here or above

Minutes

smarterwebapps-minutes