OpenmokoFramework
From Openmoko
(Difference between revisions)
m (→How to achieve that technically) |
|||
Line 18: | Line 18: | ||
* Expose features through dbus APIs implemented by UI and language-agnostic services (daemons). | * 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. | * 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= | =High Level Overview= |
Revision as of 16:50, 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 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.