Sugar architecture review 1: Difference between revisions

From OLPC
Jump to navigation Jump to search
No edit summary
m (Reverted edits by 67.223.234.160 (Talk) to last version by Salevin)
 
(8 intermediate revisions by 7 users not shown)
Line 1: Line 1:
== Presence service ==
== Presence service ==


* Turn the presence service in a DBUS service, to simplify the code and decrease network usage.
* Turn the presence service in a DBUS service, to simplify the code and decrease network usage. [[Presence Service DBus API]]
* Fix the misuse of zeroconf service types.
* <strike>Fix the misuse of zeroconf service types.</strike>
* Define an API that makes straight forward the most common case: activity specific service browing.
* Define an API that makes straight forward the most common case: activity-specific service browing.


== Activities ==
== Activities ==
Line 9: Line 9:
* It should not be necessary to write a Shell per each activity to manage multiple activities in the same process.
* It should not be necessary to write a Shell per each activity to manage multiple activities in the same process.
* Abstract activity construction.
* Abstract activity construction.
* Define the status of modules like Presence service, the one-to-one chat listener, Voip services, bots. They are definately not activity because they are not user visible and they are global services. (My current thinking is to define those as parts of the shell or anyway shell extensions).
* Define the status of modules like Presence service, the one-to-one chat listener, Voip services, bots. They are definitely not activity because they are not user visible and they are global services. (My current thinking is to define those as parts of the shell or anyway shell extensions).
* Get rid of xembed and use matchbox for window management (on the OLPC)
* Get rid of xembed and use matchbox for window management (on the OLPC)


Line 24: Line 24:
* Define contributors development tools (build, coding, testing)
* Define contributors development tools (build, coding, testing)
* Define kids development experience and write the tools
* Define kids development experience and write the tools


[[Category:Sugar]]

Latest revision as of 07:06, 17 December 2008

Presence service

  • Turn the presence service in a DBUS service, to simplify the code and decrease network usage. Presence Service DBus API
  • Fix the misuse of zeroconf service types.
  • Define an API that makes straight forward the most common case: activity-specific service browing.

Activities

  • It should not be necessary to write a Shell per each activity to manage multiple activities in the same process.
  • Abstract activity construction.
  • Define the status of modules like Presence service, the one-to-one chat listener, Voip services, bots. They are definitely not activity because they are not user visible and they are global services. (My current thinking is to define those as parts of the shell or anyway shell extensions).
  • Get rid of xembed and use matchbox for window management (on the OLPC)

Network

  • Improve multi cast reliability. The use case is out of school small groups of kids.
  • Write a server that can be used to broadcast messages instead of udp at school.
  • Define our messaging protocol (Dan to look in xmpp)
  • Identity. Completely to define.

Development tools

  • API documentation
  • Define contributors development tools (build, coding, testing)
  • Define kids development experience and write the tools