OpenmokoFramework

From Openmoko

Revision as of 16:11, 15 April 2008 by Mickey (Talk | contribs)

Jump to: navigation, search

Note: This is the (ongoing) description of the new framework architecture. See OpenmokoOldFramework for the framework architecture of 2007.1 and 2007.2

Contents

Purposes

  • Give people the infrastructure to create solid and exciting software products based on the Openmoko platform
  • Support competing UIs while collaborating on developing services

Requirements

  • Make it simple
  • Concentrate on core services
  • Be programming language agnostic
  • Be UI toolkit agnostic
  • Try to reuse existing technologies as much as possible, but not at the cost of a bad API

How to achieve that technically

  • Chose Dbus as the collaboration line. Below dbus, we can work together. Above dbus, we can differenciate.
  • Expose features through dbus APIs implemented by UI and language-agnostic services (daemons).
  • Optimize for Openmoko devices, but support multiple architectures and purposes through plugin interfaces and suitable hardware abstraction mechanisms.
  • Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.

Mandatory Readings

High Level Overview

... picture ...

Components

... discussion of subsystem purposes ...

Tasks

... explain what's already there, what's missing, what do we need to do ...

Team & Roadmap

... talk about the team and the roadmap ...

Personal tools

Note: This is the (ongoing) description of the new framework architecture. See OpenmokoOldFramework for the framework architecture of 2007.1 and 2007.2

Purposes

  • Give people the infrastructure to create solid and exciting software products based on the Openmoko platform
  • Support competing UIs while collaborating on developing services

Requirements

  • Make it simple
  • Concentrate on core services
  • Be programming language agnostic
  • Be UI toolkit agnostic
  • Try to reuse existing technologies as much as possible, but not at the cost of a bad API

How to achieve that technically

  • Chose Dbus as the collaboration line. Below dbus, we can work together. Above dbus, we can differenciate.
  • Expose features through dbus APIs implemented by UI and language-agnostic services (daemons).
  • Optimize for Openmoko devices, but support multiple architectures and purposes through plugin interfaces and suitable hardware abstraction mechanisms.
  • Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.

Mandatory Readings

High Level Overview

... picture ...

Components

... discussion of subsystem purposes ...

Tasks

... explain what's already there, what's missing, what do we need to do ...

Team & Roadmap

... talk about the team and the roadmap ...