Sugar architecture review 1: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
m (Reverted edits by 67.223.234.160 (Talk) to last version by Salevin) |
||
| (7 intermediate revisions by 6 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 |
* 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 |
* 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) |
||
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