5,705
edits
Changes
no edit summary
<noinclude>{{TOCright}}
<noinclude>{{TOCright}}
[[Category:Feature|Sugar Bundles]]
[[Category:Feature|<Feature Name>]]
<!-- You can add categories to tie features back to real deployments/schools requesting them, for example
<!-- You can add categories to tie features back to real deployments/schools requesting them, for example
[[Category:Features requested by School Xyz|<Feature Name>]] (the |Feature Name option sorts the entry on the category page under the first letter of <Feature Name>). -->
[[Category:Features requested by School Xyz|<Feature Name>]] (the |Feature Name option sorts the entry on the category page under the first letter of <Feature Name>). -->
In fact, this feature is an end users oriented(technically we not invent super format for various types of content, just unified sugar wrapper). Users all time know that there is only one type of sugar objects, they see it as a Journal item, one file with suffix ''.xo'' in non-sugar environments etc. So they need only upload this file to Journal and click to activate it.
In fact, this feature is an end users oriented(technically we not invent super format for various types of content, just unified sugar wrapper). Users all time know that there is only one type of sugar objects, they see it as a Journal item, one file with suffix ''.xo'' in non-sugar environments etc. So they need only upload this file to Journal and click to activate it.
At present we have several file types that user can encounter out of sugar:
At present, we have several file types that user can encounter out of sugar:
* activity bundles(.xo)
* activity bundles(.xo)
* content bundles(.xol)
* content bundles(.xol)
* journal bundles(.xoj)
* journal bundles(.xoj)
All these files have different suffixes and after uploading to Journal have different behaviour.
All these files have different suffixes and after uploading to Journal have different behaviour.
Sugar Bundles are intended to unify object related workflow:
* one type of objects out of sugar - files with ''.xo'' suffix
* one type of behaviour after uploading such files to the Journal - you need to click on object in Journal to activate it
So, Sugar Bundles not only changes import/export part of sugar but also change lauch workflow, uploaded objects from ''.xo'' files could be:
* ''activity_id'' less Journal entries, launch some activity to open this object
** just various files that were created out of sugar
** former Library bundles will be opened in Browse
* Journal entries with ''activity_id'', launch poper activity to open this object
* activities, launch it with newly created object
=== Specification ===
Sugar bundle should have METADATA file in the top directory(or in <some_name>/ directory) of .xo bundle. This file is in [http://docs.python.org/library/configparser.html INI] format which describes how to setup bundle.
METADATA file can have one or several sections(depends on content) that describe metadata fields of final entry(ies) in Journal and other data that could be useful for sugar(depends on content).
{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;"
|-style="background:#787878; color: white;"
! Field
! Flags
! Notes
|-
| ''entry''
| optional<br>(depends on content)
| defines access point within the bundle(e.g. index.html for library bundles)
|-
| ''mime_type''
| mandatory
| define MIME type for final Journal entry
|-
| ''uid''
| ignored
|-
| ''*''
| optional
| any [[Features/Plain_Query_Format#System_terms|system]], [[Features/Plain_Query_Format#Users_predefined_terms|users predefined]] and arbitrary Datastore field
|-
| ''*''
| optional
| any tag, depends on content(inherited from activity bundles etc.)
|-
|}
Any field in ''METADATA'' file can have ''_file'' suffix, in that case content of this field(substring w/o ''_file'' suffix) will be fetched from file inside of the bundle.
== Benefit to Sugar ==
== Benefit to Sugar ==
So if one user uploaded Journal object(any type - activity, activity object, content library etc.) to the web, another user can download/transfer-through-many-non-sugar-environments it and open in his sugar environment with keeping all metadata(he will get the same Journal entry).
So if one user uploaded Journal object(any type - activity, activity object, content library etc.) to the web, another user can download/transfer-through-many-non-sugar-environments it and open in his sugar environment with keeping all metadata(he will get the same Journal entry).
We can also collect users object on public server like ASLO to have server like sharing feature.
== Scope ==
== Scope ==
* sugar
* sugar-toolkit
== UI Design ==
Nothing except related [[Features/Activity as a regular Journal Object]] feature.
== How To Test ==
== How To Test ==
* [http://wiki.laptop.org/go/Manifest_Specification#Contents_Manifests MANIFEST specification]
* [http://wiki.laptop.org/go/Manifest_Specification#Contents_Manifests MANIFEST specification]
* Email threads
* Email threads
** [http://thread.gmane.org/gmane.linux.laptop.olpc.sugar/19495/focus=19499 Sugar Bundles request for inclusion to 0.88]
** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg10708.html Activity as a regular Journal Object request for inclusion to 0.88]
** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06874.html Object Bundles review and inclusion to 0.86/Feature_List request Object Bundles]
** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06874.html Object Bundles review and inclusion to 0.86/Feature_List request Object Bundles]
** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg07572.html multiple activity versions installed simultaneously]
** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg07572.html multiple activity versions installed simultaneously]