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)
 
(176 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 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-agnostic 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=
+
 
+
* [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]
+
* [http://www.freesmartphone.org FreeSmartPhone.org Wiki]
+
 
+
=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=
+
 
+
==What's there==
+
* bluez
+
* gypsy
+
* geoclue
+
* py-odeviced
+
* networkmanager or intel connection manager
+
 
+
==What's missing==
+
* py-ophoned
+
* pimd (GSoC 2008 project)
+
* eventd
+
* usaged
+
* preferencesd
+
* contextd
+
 
+
=Team & Roadmap=
+
 
+
... talk about the team and the 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 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-agnostic 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

What's there

  • bluez
  • gypsy
  • geoclue
  • py-odeviced
  • networkmanager or intel connection manager

What's missing

  • py-ophoned
  • pimd (GSoC 2008 project)
  • eventd
  • usaged
  • preferencesd
  • contextd

Team & Roadmap

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