Albert has deprecated this page or content because parts of it are no longer relevant, or an accurate presentation of MediaPortal 2 architecture.

MP2 Architecture Overview

Architecture Goals

• Flexible
  • Separate the functionality (tv, music, pictures etc) from the actual GUI (xaml, directx, html)
  • Separate data from behaviour
  • Separate functionality from GUI
• Stable
  • Service based
  • Clean separation of core services

Architecture Design

The architecture of MP2 consists of three major parts:

1. Core framework and services
2. Media Metadata and Database
3. Presentation and Control

These major parts and how they fit together can be seen in the following diagram.

Diagram: Architecture Overview

Core framework and services

The core framework and services provide:

• Global Service Management
• Plugin Management
• Settings Management
• Thread Management
• Messaging
• Localisation
• Logging
• Event Management (Planned)
• User Management (Planned)

The core enables MP2 to be extended thought plugins and also provides a way for plugins to communicate with each other. While taking care of many common tasks, such as the loading of settings.

Media Metadata and Database

The Media Metadata and Database of MP2 consists of:

• Providers
• Models

Providers

A provider is a plugin which hooks into the media library. A provider provides low-level data manipulation and retrieval for a specific media type (tv,music,pictures,...) A specific media can have multiple providers, each providing a specific part. (like an IMDB provider for movies) Example, the tv- provider might be split up into:

• a provider to handle recordings
• a provider to handle schedules
• a provider to handle epg

The provider to handle recordings might have:

• operations to retrieve recordings
• operations to create (new) recordings
• operations to delete recordings

Models

A Model is a plugin which hooks into the model library. A model contains the logic which is needed for the GUI. It exposes commands, which the GUI can execute and exposes collections of object to which the GUI can databind and present onscreen e.g. a model might:

• Expose a collections of objects which the gui can display (e.g. a list of recordings with all its properties)
• Expose operations like sorting
• Exposes one or more 'commands' which can be used by (any) GUI. These commands could be things like sort, play movie, delete recording,

Presentation and Control

GUI

The GUI consists of one or more screens/pages. Each page can use data & commands from ANY model. For example, the movies screen could also show the tv-recordings.

The gui itself does not contain any logic. It:

1. databinds data provided by models
2. calls commands provided by models

GUI Engine

The GUI engine is is responsible for

• Loading the skin
• Window/page management
• Rendering the GUI
• Handling input

The GUI engine itself does NOT know about any models.

The skin xml file should define which data from which model is presented (and how) and which operations of which models should be used when the user for e.g. presses a button

There can be different GUI engine e.g.

1. Xaml based
2. DirectX based
3. PDA based