| Line 5: |
Line 5: |
| | HTML5 activities will be run via a WebKit instance. A JavaScript framework will expose Sugar Features to HTML5 activities. Specifically, this framework will allow to use HTML controls matching the Sugar widgets look&feel and will expose common and customized activity toolbars. The framework will also expose API for handling Telepathy (communication and collaboration between multiple Sugar machine) and Datastore (Sugar Journal reading and writing). | | HTML5 activities will be run via a WebKit instance. A JavaScript framework will expose Sugar Features to HTML5 activities. Specifically, this framework will allow to use HTML controls matching the Sugar widgets look&feel and will expose common and customized activity toolbars. The framework will also expose API for handling Telepathy (communication and collaboration between multiple Sugar machine) and Datastore (Sugar Journal reading and writing). |
| | | | |
| − | The following schema sum up HTML5 activities architecture. | + | The following schema sum up HTML5 activities functional architecture. |
| | | | |
| | [[File:SugarWebApp Architecture.svg|400px|center]] | | [[File:SugarWebApp Architecture.svg|400px|center]] |
| Line 20: |
Line 20: |
| | = Current works = | | = Current works = |
| | HTML5 activities has been choose [http://meeting.sugarlabs.org/sugar-meeting/meetings/2013-04-22T14:04:27] as a feature for Sugar 0.100. | | HTML5 activities has been choose [http://meeting.sugarlabs.org/sugar-meeting/meetings/2013-04-22T14:04:27] as a feature for Sugar 0.100. |
| − | HTML5 activities will be build on WebKit2 but if time permits we will implement compatibility with previous releases running WebKit1 | + | HTML5 activities will be build on WebKit2 but if time permits we will implement compatibility with previous releases running WebKit1. |
| | + | HTML5 activities is accepted a project for [[Summer of Code/2013]]. |
| | | | |
| − | == IPC Communication ==
| + | A technical architecture is described [http://developer.sugarlabs.org/web-architecture.md.html here]. |
| − | Historic implementation (Wikipedia and Foodchain) use hacky ways to handle communication between Sugar and JavaScript. We need a more performance way to communicate (send API call and data).
| + | The procedure to create a web activity using from a common template is described [http://shell.sugarlabs.org/~buildbot/docs/activity.md.html here]. |
| | | | |
| − | Daniel explore communication using WebSocket [http://lists.sugarlabs.org/archive/sugar-devel/2013-April/042677.html].
| + | Some interesting discussion around this subject in the community: |
| | + | * Sugar Web Architecture [http://lists.sugarlabs.org/archive/sugar-devel/2013-June/043518.html] |
| | + | * Sugar Web UI [http://lists.sugarlabs.org/archive/sugar-devel/2013-June/043519.html] |
| | + | * Localization [http://lists.sugarlabs.org/archive/sugar-devel/2013-June/043466.html] |
| | + | * Renaming HTML --> Web [http://lists.sugarlabs.org/archive/sugar-devel/2013-May/043400.html] |
| | + | * Running HTML5 activity on other platforms [http://lists.sugarlabs.org/archive/sugar-devel/2013-June/043422.html] |
| | + | * How to deploy framework in the activity [http://lists.sugarlabs.org/archive/sugar-devel/2013-May/043335.html] |
| | + | * Datastore API [http://lists.sugarlabs.org/archive/sugar-devel/2013-May/043303.html][http://lists.sugarlabs.org/archive/sugar-devel/2013-May/thread.html] |
| | + | * Unit Testing [http://lists.sugarlabs.org/archive/sugar-devel/2013-May/043151.html] |
| | + | * Webkit1/Webkit2 compatibility [http://lists.sugarlabs.org/archive/sugar-devel/2013-May/043166.html] |
| | | | |
| | | | |
| − | == Sugar HTML Framework == | + | = TODO List = |
| − | === Sugar UI ===
| + | See TODO list of the project on [https://github.com/sugarlabs/roadmap/issues/8]. |
| − | This part of the framework should expose HTML controls matching the Sugar widgets look&feel and common and customized activity toolbars.
| |
| | | | |
| − | Manuel has done some research about components to do that [https://github.com/manuq/components-test].
| |
| | | | |
| − | === Datastore === | + | = GSoC Timeline progress = |
| − | This part of the framework should expose Datastore API into JavaScript. In a first step, the JavaScript Datastore API will just call the Sugar Datastore API. Some considerations about how to write a pure HTML5 Datastore are listed below.
| + | * Week 1: Working sugar-build environment, create a new activity [https://github.com/surajgillespie/myactivity] |
| − | | |
| − | ==== API Use case ====
| |
| − | * Called by an activity to Write/Read its context (most often seen use case)
| |
| − | * Called by Sugar or by an activity to navigate into. Query could be: | |
| − | ** Filtered by title, mime type, date, …
| |
| − | ** Ordered by one or more keys
| |
| − | ** Limited to some number of results (with an optional starting offset)
| |
| − | ==== What is a datastore object ? ====
| |
| − | * A set of properties:
| |
| − | ** Some comes from Sugar
| |
| − | ** Some are custom properties
| |
| − | ** All properties values type are: string, text, int, number, date, binary or external (file)
| |
| − | * A filename (optional)
| |
| − | ==== Proposed interface ====
| |
| − | function DataStore.create(properties, filename); // Return object_id
| |
| − | function DataStore.get_properties(object_id); // Return set of properties as JSON object
| |
| − | function DataStore.get_filename(object_id); // Return filename
| |
| − | function DataStore.find(query, properties); // Return array of object_id
| |
| − | function DataStore_created(object_id); // Callback interface to object_id created event
| |
| − | function DataStore.addEventListener("created", DataStore_created);
| |
| − | function DataStore_Updated(object_id); // Callback interface to object_id updated event
| |
| − | function DataStore.addEventListener("updated", DataStore_updated);
| |
| − | function DataStore_Deleted(object_id); // Callback interface to object_id deleted event
| |
| − | function DataStore.addEventListener("deleted", DataStore_deleted);
| |
| − | | |
| − | function write_file(properties, filename);
| |
| − | function Activity.addEventListener("write", write_file);
| |
| − | function read_file(properties, filename);
| |
| − | function Activity.addEventListener("read", read_file);
| |
| − | | |
| − | ==== HTML5 implementation consideration ====
| |
| − | * DataStore and Activity will be new JavaScript namespace.
| |
| − | * This interface is mostly inherited from the existing sugar.datastore.store API [http://wiki.sugarlabs.org/go/Development_Team/Almanac/sugar.datastore.datastore]. By the way it make sense to reproduce these features because basically the Sugar DataStore can't be something else than a place to store files and metadata related to files.
| |
| − | * Files handling is possible directly in JavaScript - WebKit only - using File API [http://dev.w3.org/2009/dap/file-system/pub/FileSystem/][http://dev.w3.org/2009/dap/file-system/file-writer.html]. Alternatively we could consider than file storage will be handle by the JavaScript to Sugar interface.
| |
| − | * Event registration ("addEventListener") is inspired by the DOM events model thought it's not directly connected to it.
| |
| − | * Activity events should be raised by the JavaScript to Sugar interface.
| |
| − | | |
| − | | |
| − | === Telepathy ===
| |
| − | This part of the framework should expose Telepathy API into JavaScript.
| |
| − | | |
| − | TODO
| |
| − | | |
| − | === Template ===
| |
| − | A template will be provide to developers to write its own activity. This template will include the Sugar HTML Framework.
| |
| − | | |
| − | Daniel has wrote a first template [http://lists.sugarlabs.org/archive/sugar-devel/2013-April/042710.html].
| |
| − | | |
| − | == HTML Activities ==
| |
| − | HTML activties will be developed in parallel with the framework development.
| |
| − | | |
| − | Manuel has started to port the Clock activity using HTML5 Canvas [http://lists.sugarlabs.org/archive/sugar-devel/2013-April/042706.html].
| |
| − | | |
| − | == Other services needed==
| |
| − | | |
| − | Implementing demo activities is good to identify what services are not available or need more work on javascript.
| |
| − | | |
| − | These are identified right now:
| |
| − | | |
| − | * gettext
| |
| − | * text to speech
| |
| − | * touch support?
| |
| − | * power management (in the clock activity, we need a way to tell the xo don't suspend)
| |
| − | | |
| − | = TODO List =
| |
| − | Find [[HTML5 activities/TODO]] the todo list on this task.
| |