Backend class

From Apibot

Jump to: navigation, search

Contents

Description

As of July 2014, MediaWiki has two interfaces - the human-oriented Web interface and the bot-oriented API interface. They do almost the same things, but communicate in a different way. In the future, more MediaWiki interfaces may appear - for example, a new API interface that is not backwards-compatible with the current one. In addition, there are other wiki software packages, which do generally the same things as MediaWiki, but communicate in a different way.

All this means that Apibot should better be able to do the same things by communicating in more than one way. This is achieved by defining different backends - communication "drivers" that present a standard appearance to the bot core, and care to translate the commands and responses into the different interface "languages" used by the different interfaces.

Currently Apibot has two backends. The default one is called API and works through the MediaWiki API interface. There is also another one, called Web and working through the MediaWiki Web interface. The MediaWiki API interface is created for usage by bots; Apibot supports all of its functionality. The MediaWiki Web interface is not designed for bots and Apibot supports only some of its functions. However, it was historically the first MediaWiki interface and for a long time some MediaWiki functions were available only through it. Even today, many extensions support only the MediaWiki Web interface, and thus their functionality is available only through it.

The basic functionalities of Apibot are classified in two types - queries and tasks. The queries are currently supported only by the API backend. (Making a Web interface support for them would not be easy, and might be impossible for some.) Of the tasks, some are supported only by the API backend and others are supported by both backends.

To hide the intricacies of the backends handling, on top of the backends are defined two kinds of backend-independent objects - Queries and Tasks. To implement their functionality, they choose internally one of the available backends to do it. The Bridge interface functions work through these backend-independent objects, as well as the Assembly line interface.

Contained objects

The Backend object is a container object which supports as properties the following backend-specific objects:

  • $exchanger (Exchanger) - handles the MediaWiki-specific data transfers.
  • $identity (Identity) - stores and exports the account identity related settings and info
  • $info (Info) - a backend-specific Info class
  • $tokens (Tokens) - stores and exports the MediaWiki request tokens.

In addition, the Backend object links as properties the following backend-independent objects from the Core object that owns it:

  • $settings (Settings) - stores and exports the settings the bot was created with
  • $browser (Browser) - handles HTTP(S) connections, eg. these between the bot and the MediaWiki
  • $infostore (Infostore) - saves to file(s) and retrieves cached information. (Used by the Info and Identity objects, but you also may use it for your own info.)
  • $log (Log) - enables the logging by the bot modules
  • $hooks (Hooks) - enables inserting your callbacks at specific places in the bot parameters or data flow.

Implementation

The backends code is in the backends/ directory of the bot. The generic classes are in backends/_generic/, the API backend is in backends/api/ and the Web backend is in backends/web/.

Each backend path has several subpaths in it:

  • modules/ - the modules classes of the Module level
  • querymodules/ - the querymodules classes of the Module level
  • mainmodule/ - the Mainmodule class
  • pagesetmodule/ - the Pagesetmodule class
  • actions/ - the classes of the Action level
  • queries/ - the backend-specific Query classes
  • tasks/ - the backend-specific Task classes
  • core/ - the Backend object and the objects that are its backend-specific properties

Currently, only the API backend has all of these subpaths. The Web interface has only modules/, actions/, tasks/ and core/ - the functionality in the other directories is not implemented yet.

Hooks

These Backend functions can be hooked to through the Hooks module. Each of them returns the corresponding backend-specific object that will be contained in this Backend object:

Function (with hook callback profile) Since Apibot version
new_exchanger ( $hook_object, $base_url, $settings_array, $default_params, $log_object, $browser_object, $hooks_object ) v0.40.10
new_identity ( $hook_object, $exchanger_object, $infostore_object, $hooks_object, $settings_object, $backend_name ) v0.40.10
new_info ( $hook_object, $exchanger_object, $infostore_object, $identity_object, $hooks_object, $settings_object ) v0.40.10
new_tokens ( $hook_object, $exchanger_object, $info_object, $hooks_object, $settings_object ) v0.40.10

The hook names differ for the Exchanger_API and Exchanger_Web classes, as follows:

Backend_API Backend_Web
Backend_API::new_exchanger Backend_Web::new_exchanger
Backend_API::new_identity Backend_Web::new_identity
Backend_API::new_info Backend_Web::new_info
Backend_API::new_tokens Backend_Web::new_tokens
Personal tools