Managing Sets of Program Resources

Using Content Negotiation for automated
Resource Handling

Christian Langanke for netlabs.org

Overview

• Intention of this session
• eComStation Resource Handling /
  Managing Sets of Resources / Drawbacks
• Web Content Negotiation / Example / Workflow / Benefits
• Adopting Content Negotiation for conventional programming
• Content Negotiation: Components / Workflow /
  Benefits / New features
• What is next / Key Messages / Questions and Answers

Intention of this session

• This session presents a design idea for Voyager
  
• The presented concept is subject to further discussion
  
• No code exists yet -
  Code snippets are included as examples only

eComStation Resource Handling

• standard methods
  • VIO programs use message files to load strings
  • PM Programs
  • use resource DLLs to load strings, dialogs and bitmaps
  • load bitmaps/pointers/icons directly from respective files
  • show panels of help and inf files
• alternative methods
  • some programs use the Text Message File (TMF) API of the Workplace Shell Toolkit
  • xWorkplace uses a modified/extended version of TMF
  • programs may use other concepts ported to OS/2
    • read messages with gettext
    • read messages/other data from XML files by libxml
  • more...

Managing Sets of Resources 1/3

• General steps for managing Sets of Resources

• Step 1: Determine resources to be used

• Step 2: make resources available for the application

• Step 3: use resources

Managing Sets of Resources 2/3

• Step 1 - Determine resources
  • standard used case: language
    • determine the language (either user or system defined) and fallback language
    • determine the languages supported by the application
    • finally: determine the language to be used

  • standard used case: video attributes
    • --- applies only to where graphic files cannot/do not hold more than one variant of a resource !!! ---
    • determine the resolution/color depth

  • application specific used case: license type
    • read license key (from file/os2.ini/...)
    • determine license, distinct e.g. between lite, standard and pro version

Managing Sets of Resources 3/3

• Step 2 - make resources available
  • load the file containing the resources for the used language
  • store a handle to a resource DLL, TMF instance, XML parser instance etc.
  • create a help instance
• Step 3 - use resources
  • load a dialog, bitmap, pointer, etc.
  • create a dialog in memory from resources read from other sources
  • load a help panel
  • launch view.exe with the name of a panel

  • mostly done by the system API:
    decoding of complex resource data (e.g. bitmaps and dialog templates)

Drawbacks of current situation

• Things to code for every application
  • Step 1: determine the set of resources to be used
  • Step 2: find and load resource files within the application directory tree
• Available options:
  • copy&paste of code between source code of applications
  • create own library
  • use the Workplace Shell Toolkit API for handling resource files at least for different languages
• no standard method available

Web Content Negotiation

• Apache MultiViews implement Content Negotiation for automated selection between resource variants
  • see V.O.I.C.E. issue 12/2001:
    • Multi-language websites with Apache web server
    • Mehrsprachige Webseiten mit dem Apache Webserver
• Used terms / required components:
  • a Resource Variant is a specific representation of a resource
  • a Resource Dimension specifies in which way a variant may vary
    • dimensions can be combined, so that a given variant of a resource must match more than one dimension
    • within a website the number of supported dimensions may vary per resource (that is: per file)
  • a Preference List for a given dimension defines, which variants are preferred over others

Resource Dimensions/Variants

Preference Lists

• Preference Lists for selected dimensions
  • are defined within the Web browser
  • added to each browser request as one or more HTTP headers
• Supported Dimensions/Examples
  • Language:
    • HTTP Header: Accept-Language: de,en
    • Configure in Firefox in
      Tools - Options... - Advanced - Edit Languages...
  • Media Type:
    • HTTP Header:
      Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; q=0.8,image/png,*/*;q=0.5
  • Character Set:
    • HTTP Header: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
  • Compression:
    • HTTP Header: Accept-Encoding: gzip,deflate

Web Content Negotiation Workflow

Web Content Negotiation Benefits

• existance of different resource variants is completely transparent to the Web Browser
  • links to subpages are identical for all variants
  • no language codes in links to translate
  
  
• full user control for languages by web browser configuration
  • no need to click on flags or links to switch languages
  • web pages automatically show up in the preferred version (e.g. language), if available (otherwise in default version)

Adopting Content Negotiation

Keep, modify or add the following in the Web scenario, and for the scenario of conventional programming

• components

• tasks
• (parts of) workflow

Components: Web Scenario

Components: Programming Scenario

Content Negotiation Components 1/3

• Resource Dimension
  • is defined by
    • a user-defined name (unique to the application)
    • a handler to detect the current value for the dimension
    • the fallback dimension value

  • the system provides handlers for standard dimensions
  • the application can implement own handlers
  • the handler determines all valid dimension values for the Resource Dimension, for example
    • all language codes supported by the system, or of RFC 1766 or ISO 639-1
    • all valid video resolutions provided by the installed video driver

Content Negotiation Components 2/3

• Resource Set
  • is defined by
    • a user-defined type name (unique to the application)
    • values for dimensions supported by it
    • an optional fallback Resource Set for missing resource entities

  • is encoded in one file of any format
  • contains resource entities for a given variant
  • is handled and decoded by a Resource Set Decoder

Content Negotiation Components 3/3

• Resource Set Decoder
  • consists of code to handle and decode a file of a given Resource Set format
    • determine and validate the file type
    • claim responsability for a file
    • determine the variant information of the file
    • retrieve the fallback variant, if provided
    • retrieve a module handle, where applicable
      (e.g. from a resource DLL or a parser instance)
    • retrieve or view a resource entity
    • translate complex resource data to a format required by the system API, where required

  • the system provides decoders for standard formats
  • the application can implement own decoders
  • the application can replace system-provided decoders, fully or for certain files and/or tasks

Content Negotiation Workflow 1/6

• On application start, the application registers its Resource Dimensions

  

Content Negotiation Workflow 2/6

• On application start, the application registers its Resource Sets

  

Content Negotiation Workflow 3/6

• processing the registration, the system
  • creates a table of Resource Dimensions
  • passes names of matching files to the available Resource Set Decoders
  • creates a table of Resource Sets for all valid files, including the full variant information

Content Negotiation Workflow 4/6

• a request for a resource via the System API specifies
  • the Resource Set Type Name, e.g. "res_DLL" or "helpfile"
  • the resource entity identifier, e.g. RT_DIALOG, 0x1204 or "InfoDialog"
  • optionally override dimension values, e.g. "license_type=pro"

    

Content Negotiation Workflow 5/6

• processing the request, the System API
• retrieves the values of all used dimensions from the Resource Dimension Handlers (where not determined by the request)
• assembles the full variant information for the request

Content Negotiation Workflow 6/6

• further processing the request, the System API
• determines the matching Resource Set
• calls the Resource Set Decoder for that set to decode the resource file and retrieve or view the resource entity

Content Negotiation: Benefits

• no more need to code for handling of
  • standard dimensions
  • resource files
• flexible by fallback mechanisms
  • fallback value for Resource Dimension
  • fallback Resource Set for missing resource entities
• System API comes with standard modules
  • handlers for dimensions
  • decoders for resource files
• highly extendible - both application or System API can easily be extended to support
  • new system or application specific dimensions by new handlers
  • new resource file types by new decoders

Content Negotiation: new features

• dimensions like language can be modified system wide
  • user could drag a locale object to an application window or the desktop
  • system would send notifications either to the application window or the desktop window and all application windows
    
  • the window manager would react on the notification by
    • reloading application dialogs and other GUI components, using the appropriate variant
    • notify the dialog to allow update of dynamic content
  • difference to today: window manager and GUI classes would implement most of the automation, not the applications
• similar can be implemented for video attributes changing on the fly
  • could be useful when having that ability with Neptune

What is next ?

• design and implement the System API, depends on
  • overall System API layout
  • programming paradigm of the GUI
• design the module interfaces for
  • Resource Dimension handlers
  • Resource Set Decoder
  these could base on any module/plugin framework
• implement standard modules for the System API
• for decoders, design/implement data formats and translation, where required

Key Messages

• The concept of using Content Negotiation for conventional programming
  • will ease development of applications supporting multiple languages or other resource dimensions

  • is highly extendible, so it is future safe

  • allows implementation of new features on the Voyager platform if being used as a standard

Questions and Answers

• Your questions ?
• Your suggestions ?
• Your comments ?

The End

Thank you very much for your your attention!