OpenmokoFramework

From Openmoko

(Difference between revisions)
Jump to: navigation, search
m (How to achieve that technically)
(moving to FSO as that term is used more often)
 
(192 intermediate revisions by 37 users not shown)
Line 1: Line 1:
''Note: This is the (ongoing) description of the new framework architecture. See [[OpenmokoOldFramework]] for the framework architecture of 2007.1 and 2007.2''
+
#REDIRECT [[FSO]]
 
+
=Purposes=
+
 
+
'''Give people the infrastructure to create solid 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.
+
* Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.
+
 
+
=High Level Overview=
+
 
+
=Components=
+
 
+
=Tasks=
+
 
+
=Roadmap=
+

Latest revision as of 17:08, 3 July 2009

  1. REDIRECT FSO
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 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.
  • Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.

High Level Overview

Components

Tasks

Roadmap