Sugar architecture review 1: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 10: | Line 10: | ||
* 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 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). |
||
* 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 |
Revision as of 02:49, 30 June 2006
Presence service
- Turn the presence service in a DBUS service, to simplify the code and decrease network usage.
- 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 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).
- 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