Difference between revisions of "Administration design"
(→Brainstorm area) |
(add scenario mode) |
||
| (23 intermediate revisions by 5 users not shown) | |||
| Line 3: | Line 3: | ||
GCompris contains a lot of activities for children in a large age range. It is used at home and at schools. | GCompris contains a lot of activities for children in a large age range. It is used at home and at schools. | ||
| − | Home users can easily follow their children and propose them the most appropriate activities. But using it in classrooms brings a new set of requirements: | + | Home users can easily follow their children and propose them the most appropriate activities. But using it in classrooms brings a new '''set of requirements''': |
| − | * | + | * Maintain students/teachers/groups/profiles |
| − | |||
| − | |||
| − | |||
| − | * | + | * Profiles |
| + | ** activity filter (difficulty filter or activity list) | ||
| + | ** activity configuration (like uppercase only) | ||
| + | ** create and assign activity dataset | ||
| + | ** create and assign a scenario. A scenario is a list of [activity/level/configuration] that a children must follow. It replaces the traditional menu. | ||
| + | |||
| + | * Collect and report students results | ||
** must be as real time as possible to let the teacher help the children asap | ** must be as real time as possible to let the teacher help the children asap | ||
| − | ** | + | ** longterm statistical reports |
| + | * Distribute activities (as rcc files) | ||
| − | + | * Share datasets and activities with other teachers/schools | |
| − | + | * Web storage and sharing of children's creation | |
| − | + | * Private text chat with the ability to share a drawing or send it. | |
| − | + | * Pause or mute the set of GCompris under the teacher's control. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | == Schoolbus System Architecture == | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | * | + | * Centralization of a backend service (schoolbus) that is supposed to run on gcompris.net as well as (optionally) as an installation in LAN/school scope. |
| − | |||
| − | |||
| − | * | + | * The core of the central service comprises an access layer (API) and a storage layer (DB). All data access happens through the API. Optionally a web interface may be needed to administrative the central service itself (not the admin content), which then would also use the API. |
| − | |||
| + | * DB store: Could use a RDBM or a non-relational, key-value based DB. Will be decided based on datamodel complexity ... | ||
| − | + | * For the gcompris.net installation daily (or so) backups of the DB are expected to be enough. | |
| − | + | * To be better able to cope with outage of the server or the network the GCompris client could store a backup of the last known profile data to be used as fallback. | |
| − | |||
| − | |||
| − | + | * Protocol: For communication with the API Websockets can be used as well as HTTP. Websockets have the advantage of bidirectional communication and can be used both by web-based clients as well as native clients. Over the low level protocol an ASCII based payload (like JSON RPC) will be used to call API methods and return results back. | |
| − | + | * A QML based admin console might live as an admin activity inside the GCompris application and be unlocked in some way. Serves for administrative access to the content via the backend API. | |
| − | + | * Direct communication from users to the admin-application could be used to directly report result for the live view unless storing the results is not needed. This would relieve the central server. | |
| − | + | [[Category:English]] | |
Latest revision as of 00:16, 13 February 2016
High level overview
GCompris contains a lot of activities for children in a large age range. It is used at home and at schools.
Home users can easily follow their children and propose them the most appropriate activities. But using it in classrooms brings a new set of requirements:
- Maintain students/teachers/groups/profiles
- Profiles
- activity filter (difficulty filter or activity list)
- activity configuration (like uppercase only)
- create and assign activity dataset
- create and assign a scenario. A scenario is a list of [activity/level/configuration] that a children must follow. It replaces the traditional menu.
- Collect and report students results
- must be as real time as possible to let the teacher help the children asap
- longterm statistical reports
- Distribute activities (as rcc files)
- Share datasets and activities with other teachers/schools
- Web storage and sharing of children's creation
- Private text chat with the ability to share a drawing or send it.
- Pause or mute the set of GCompris under the teacher's control.
Schoolbus System Architecture
- Centralization of a backend service (schoolbus) that is supposed to run on gcompris.net as well as (optionally) as an installation in LAN/school scope.
- The core of the central service comprises an access layer (API) and a storage layer (DB). All data access happens through the API. Optionally a web interface may be needed to administrative the central service itself (not the admin content), which then would also use the API.
- DB store: Could use a RDBM or a non-relational, key-value based DB. Will be decided based on datamodel complexity ...
- For the gcompris.net installation daily (or so) backups of the DB are expected to be enough.
- To be better able to cope with outage of the server or the network the GCompris client could store a backup of the last known profile data to be used as fallback.
- Protocol: For communication with the API Websockets can be used as well as HTTP. Websockets have the advantage of bidirectional communication and can be used both by web-based clients as well as native clients. Over the low level protocol an ASCII based payload (like JSON RPC) will be used to call API methods and return results back.
- A QML based admin console might live as an admin activity inside the GCompris application and be unlocked in some way. Serves for administrative access to the content via the backend API.
- Direct communication from users to the admin-application could be used to directly report result for the live view unless storing the results is not needed. This would relieve the central server.
