OpenmokoFramework

From Openmoko

(Difference between revisions)
Jump to: navigation, search
m (How to achieve that technically)
(High Level Overview)
Line 19: Line 19:
 
* Optimize for Openmoko devices, but support multiple architectures and purposes through plugin interfaces and suitable hardware abstraction mechanisms.
 
* 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.
 
* Be not afraid of reinventing the wheel for a wheel-barrow if all the existing wheels are made for sports cars.
 +
 +
=Mandatory Readings=
 +
 +
* [http://adam.gomaa.us/blog/frameworks-exist-for-conceptual-integrity/ Frameworks exist for conceptual integrity]
 +
* [http://humanized.com/weblog/2007/10/05/make_oss_humane/ Ten ways to make more humane open source software]
  
 
=High Level Overview=
 
=High Level Overview=
 +
http://humanized.com/weblog/2007/10/05/make_oss_humane/
  
 
=Components=
 
=Components=

Revision as of 15:09, 15 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

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

http://humanized.com/weblog/2007/10/05/make_oss_humane/

Components

Tasks

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.

High Level Overview

Components

Tasks

Roadmap