Architecture

Revision as of 10:27, 30 March 2011

MeeGo Architecture

MeeGo architecture team is responsible for defining and managing the MeeGo architecture. MeeGo architecture consists of Core OS layer and number of UX verticals on top the Core OS layer. The architecture team decides which component to use for the functionality needed in MeeGo with the objective of consistency inside the Core OS and to the applications that run above it.

Team

• Arjan van de Ven, Chief Architect, responsible for MeeGo architecture
• Sakari Poussa, Core OS Architect, responsible for Core OS architecture
• Mikko Ylinen, Handset UX Architect, responsible for Handset UX architecture
• Sunil Saxena, Core OS Architect, responsible for Core OS architecture

Communication

• MeeGo architecture mailing list

Process

• Architecture team meets once a week. Currently the meetings are not public.
• Agenda and minutes of the meetings will be posted to the meego-architecture mailing list
• Anyone can propose topics to the architecture team agenda
• Architecture topics can and should be discussed on meego-architecture mailing list
• Architecture team is responsible of making the decision in case consensus is not reached

Process Improvement Topics

• How to make the architecture meetings open. Not all the topics can be open but most can be. Examples of non-open parts includes topics which involves IPR, legal, patent, business, product or schedule sensitive material.

Documentation

• Developer Documentation: APIs, tutorials, videos, examples ([1]), to be published soon
• Architecture Documentation: High level architecture pictures and description ([2])
• Developer and Subsystem Documentation: Detailed technical description of each MeeGo subsystem. Guidelines for developers working on MeeGo. (Architecture/Documentation)

Meetings

• Architecture/Meetings - Meetings - agenda, minutes

Upcoming Features

MeeGo Bugzilla lists the following features for MeeGo 1.2. The below proposal are all accepted and are on their way to MeeGo 1.2 release.

• Display backlight and keyboard backlight control: 5525, 5526, 5527, 5528
  • Proposal 1: Maemo 6 MCE
    • MCE provides activity monitoring and notifications via D-Bus, controls display and backlight, ALS reading and display tuning, airplane mode

• Sharing: 8179, 8180, 8181
  • Proposal 1: Maemo6 Sharing framework
    • Sharing framework provides a unified API for sharing files via, e.g., BT, email, web services. It includes webupload engine and an API for transfer UI

• Qt style APIs (that are not covered by Qt Mobility) for display backlight control, alarm/time, heartbeat, system state, thermal
  • Proposal 1: Maemo6 QmSystem
    • QmSystem provides Qt style public APIs for various system services that are not covered by Qt Mobility

• Profiles: 5771, 5750, 2889
  • Proposal 1: Maemo6 profiled
    • profiled provides a daemon and libraries to access and control profiles related data in the device. The libprofile (C) and libprofile-qt (Qt) are interfaces for the profile client to connect to the server using D-Bus. The profiled data is stored in ‘ini’ files which can be customized per different releases.

• Ringtones+feedback: 2889
  • Proposal 1: Maemo6 NGF (non-graphic feedback)
    • The device has functionality to alert user of a call, alarms and notification (SMS, email, chat, system update) events. Events may or may not have a graphical part and it may have different behavior depending on the system state. Example of this is receiving an SMS message when there is no other activity and SMS message during a call. NGF provides a unified API for apps to request logical events. The actions (e.g,. play/show LED+audio+vibra) are combined in NGF and consistent look&feel is provided.

• PIM Storage in Evolution Data Server (EDS) and email via Camel, SyncEvolution as sync engine
  • architecture decision to move towards EDS and Camel announced
  • planning in progress

Tools

Architecture tools

• Architecture navigation tool - able to browse meego packages and visually see the dependencies (coming in Nov)