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!