OpenmokoFramework

From Openmoko

(Difference between revisions)
Jump to: navigation, search
m (Components)
(high level)
Line 54: Line 54:
 
* gps
 
* gps
  
== high level ==
+
==High Level==
  
===pimd===
+
===PIM===
** intelligent storage database
+
* intelligent storage database
  
===eventd===
+
===Events===
** signaling events via I/O (ringing, blinking, vibrating)
+
* signaling events via I/O (ringing, blinking, vibrating)
** might use fd.o notification API
+
* might use fd.o notification API
  
===usaged===
+
===Usage===
** coordinating application I/O requirements (think ''reference counting'' for I/O requirements)
+
* coordinating application I/O requirements (think ''reference counting'' for I/O requirements)
** might use fd.o policy API
+
* might use fd.o policy API
  
===preferencesd===
+
===Preferences===
 +
* settings database
 +
 
 +
===Context===
 +
* Intelligent context API, integrating location as one -- among other -- sources
  
 
=Tasks=
 
=Tasks=

Revision as of 15:29, 24 April 2008

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
  • Encourage framework users (e.g. application developers) to also contribute to the framework

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

What this is NOT about

This initiative does not cover low level services such as the

  • Bootloader,
  • Kernel,
  • System Init,

This initiative does not cover high level services as the

  • X-Window-System,
  • Window Manager,
  • Application Launcher,

Overview

... picture ...

Components

... discussion of subsystem purposes ...

low level

  • device
  • gsm
  • bluetooth
  • network
  • gps

High Level

PIM

  • intelligent storage database

Events

  • signaling events via I/O (ringing, blinking, vibrating)
  • might use fd.o notification API

Usage

  • coordinating application I/O requirements (think reference counting for I/O requirements)
  • might use fd.o policy API

Preferences

  • settings database

Context

  • Intelligent context API, integrating location as one -- among other -- sources

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
  • Encourage framework users (e.g. application developers) to also contribute to the framework

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

What this is NOT about

This initiative does not cover low level services such as the

  • Bootloader,
  • Kernel,
  • System Init,

This initiative does not cover high level services as the

  • X-Window-System,
  • Window Manager,
  • Application Launcher,

Overview

... picture ...

Components

... discussion of subsystem purposes ...

low level

  • device
  • gsm
  • bluetooth
  • network
  • gps

High Level

PIM

  • intelligent storage database

Events

  • signaling events via I/O (ringing, blinking, vibrating)
  • might use fd.o notification API

Usage

  • coordinating application I/O requirements (think reference counting for I/O requirements)
  • might use fd.o policy API

Preferences

  • settings database

Context

  • Intelligent context API, integrating location as one -- among other -- sources

Tasks

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

Team & Roadmap

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