# Module: OBML_COMM

## About this module

The OBML_COMM module handles the retrieval of OBML (Opera Mini encoded) resources for presentation.

The source includes the load handler and the request and communcation management classes and the datastream based record encoding classes.

## Visibility in Opera

### Interactions inside Opera

If Opera is compiled with `OBML_2D_SUPPORT` (controlled by the feature `FEATURE_OBML2D`) then this module provides the functionality for retrieving OBML content from a configured Mini server.

## BTS

obml_comm bugs are flagged with the string `[OBML]` in the Summary field and usually have the component "Core-Network".

## Interface overview and API documentation

API documentation generated by Doxygen contains all necessary information. Note that this is currently only a full doxygen run over the entire source code of the module. A better API overview will be available shortly.

This module uses a configuration file to provide the possibility of using the same binary with different installations. The configuration file is signed with a 2042 bit RSA key (DES-EDE3-CBC) and has a mechanism for expiration.

For imformation regarding keys and signing of the configuration file please see the README.txt file located in the config directory of this module.

The configuration file can be used to override the default values for certain tweaks. The tweaks that can be overridden are:

Tweak | Comment
TWEAK_OBML_BRAND | The brand name used by the product when communicating with either Mini servers or Turbo proxy.
TWEAK_OBML_COMM_SERVER_NAME | The name of the Mini servers to use for OBML transcoding.
TWEAK_OBML_HTTP_COMM_SERVER_NAME | The name of the HTTP proxy to use for accessing the Mini servers for OBML transcoding.
TWEAK_OBML_COMM_PROXY_NAME | The Opera Turbo Proxy (OTP) to use when Opera Turbo (HTML) is enabled.

The configuration file should be packaged with a product at a location pointed out by the following .ini setting: [Proxy] Web Turbo Config File=

## Implementation description

### Overview

Implementation documentation generated by Doxygen contains what you need to know.

### Footprint

The module is small and can be disabled completely.

### Dynamic memory use and OOM handling

OOM policies

  Since the obml_comm module runs as a client of the URL module, it generally uses the same OOM outward signalling mechanisms as the URL module.

  An OOM result is generally signalled through a call on `MemoryManager::RaiseCondition`, while at the same time an error code is posted to the URL layer: either returned as a COMM_REQUEST_FAILED error from `URL_OBML_LoadHandler::Load()` or posted as an error on that load handler.

  Internally in the module OOM is usually handled by propagating OP_STATUS values.

Who handles OOM?

  Whoever created the load handler and called `URL_OBML_LoadHandler::Load()` on it must be prepared to handle OOM, signalled as described above. The obml_comm module only performs local cleanup, making sure that things remain consistent and leak-free. Generally the responsibility falls on the URL module.

Flow

  Main entry points to the module are:

  - `URL_OBML_LoadHandler::Load()`
  - `URL_OBML_LoadHandler::HandleCallback()`

  Also see the general implementation description, above.

Improvements

  There are no planned improvements. The main goal of this module is to mimic the behaviour of the Java Mini client regarding its transfer protocol implementation.