Features/Sugar Bundles: Difference between revisions

(27 intermediate revisions by 2 users not shown)

Line 1:

<noinclude>{{TOCright}}

~~[[Category:Feature Page Incomplete]]~~

[[Category:Feature|Sugar Bundles]]

[[Category:Feature|~~<Feature Name>~~]]

<!-- 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>). -->

</noinclude>

~~'''Comments and Explanations:'''~~

== Summary ==

One file format to transfer various types of content in/out to/from sugar environment with keeping metadata.

There are comments (in italic) providing guidance to fill out each section, see also [[Features/Policy]]. '''Copy the source to a ''new page'' named Features/''Your Feature Name'' before making changes! DO NOT EDIT THIS TEMPLATE.'''

== Owner ==

~~<!-- All fields on this form are required to be accepted.~~

* Name: [[User:alsroot| Aleksey Lim]]

~~We also request that you maintain the same order of sections so that all of the feature pages are uniform. -->~~

* Email: [[Special:Emailuser/alsroot|send an email]]

~~~~

== Current status ==

== ~~Summary~~ ==

* Targeted release: 0.88

''~~A sentence or two summarizing what~~ this ~~feature is~~ and ~~what~~ it ~~will do~~. ~~This information is used for~~ the ~~overall feature summary page for each release~~.''

* Last updated: Wed Nov 25 18:10:45 UTC 2009

* Percentage of completion: 0%

== Detailed Description ==

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:

* activity bundles(.xo)

* content bundles(.xol)

* journal bundles(.xoj)

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 ===

~~== Owner ==~~

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.

''This ~~should link to your home wiki page so we know who you are''~~

* Name: [~~[User~~:~~AcountName| Your Name]~~]

~~''Include you email address that you~~ can ~~be reached should people want to contact you about helping with your feature, status is requested,~~ or ~~technical issues need to~~ be ~~resolved''~~

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).

* Email: <your email address so we can contact you, invite you to meetings, etc.>

== ~~Current status~~ ==

{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;"

* Targeted release: (~~SUGAR_VERSION~~)

|-style="background:#787878; color: white;"

* ~~Last updated:~~ (~~DATE~~)

! Field

* Percentage of completion: XX%

! 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.)

|-

|}

~~== Detailed Description ==~~

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.

''~~Expand on the summary~~, ~~if appropriate. A couple sentences suffices to explain~~ the ~~goal, but the more details you can provide the better~~.''

== Benefit to Sugar ==

''What is the benefit to the platform? If this is a major capability update, what has changed? If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?''

''~~Make sure~~ to ~~note here as well~~ if ~~this feature has been requested by a specific deployment~~, ~~or if~~ it ~~has emerged from a bug report~~.''

Out of sugar environment, users know that there is only one type of sugar objects and only thing they should do to activate them is uploading ''.xo'' file to Journal and click it.

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 ==

~~''What work do the developers have to accomplish to complete the~~ feature ~~in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?''~~

* sugar

* sugar-toolkit

== UI Design ==

Nothing except related [[Features/Activity as a regular Journal Object]] feature.

== How To Test ==

{{:{{PAGENAME}}/Testing}}

== User Experience ==

''~~If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice~~.''

Since we have only one type of sugar objects, user all time knows that if there is a file with suffix ''.xo'' he can download/open-in-journal it and need only click to activate it in sugar.

== Dependencies ==

''What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate? Other upstream projects like python?''

Nothing except existed sucrose dependencies.

== Contingency Plan ==

~~''If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "~~None necessary, revert to previous release behaviour.~~" Or it might not. If you feature is not completed in time we want to assure others that other parts of Sugar will not be in jeopardy.''~~

None necessary, revert to previous release behaviour.

== Documentation ==

~~''Is there upstream documentation on this feature, or notes you have written yourself? Has this topic been discussed in the mailing list or during~~ a ~~meeting? Link~~ to ~~that material here so other interested developers can get involved~~.''

* [[Unified Bundles]]

* [[User:Alsroot/trash/Unified Objects | Unified Objects]]

* [http://wiki.laptop.org/go/Journal_entry_bundles Journal entry bundles]

* [http://wiki.laptop.org/go/Bundle_concepts Bundle concepts]

* [http://wiki.laptop.org/go/Manifest_Specification#Contents_Manifests MANIFEST specification]

* 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/msg07572.html multiple activity versions installed simultaneously]

** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06944.html Activity as regular objects proposal]

== Release Notes ==

@@ Line 1: / Line 1: @@
 <noinclude>{{TOCright}}
-[[Category:Feature Page Incomplete]]
+[[Category:Feature|Sugar Bundles]]
-[[Category:Feature|<Feature Name>]]
 <!-- 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>). -->
 </noinclude>
-'''Comments and Explanations:'''
+== Summary ==
+One file format to transfer various types of content in/out to/from sugar environment with keeping metadata.
-There are comments (in italic) providing guidance to fill out each section, see also [[Features/Policy]]. '''Copy the source to a ''new page'' named Features/''Your Feature Name'' before making changes!  DO NOT EDIT THIS TEMPLATE.'''
+== Owner ==
-<!-- All fields on this form are required to be accepted.
+* Name: [[User:alsroot| Aleksey Lim]]
- We also request that you maintain the same order of sections so that all of the feature pages are uniform.  -->
+* Email: [[Special:Emailuser/alsroot|send an email]]
-<!-- The actual name of your feature page should look something like: Features/Your Feature Name.  This keeps all features in the same namespace -->
+== Current status ==
-== Summary ==
+* Targeted release: 0.88
-''A sentence or two summarizing what this feature is and what it will do. This information is used for the overall feature summary page for each release.''
+* Last updated: Wed Nov 25 18:10:45 UTC 2009
+* Percentage of completion: 0%
+== Detailed Description ==
+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:
+* activity bundles(.xo)
+* content bundles(.xol)
+* journal bundles(.xoj)
+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 ===
-== Owner ==
+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.
-''This should link to your home wiki page so we know who you are''
-* Name: [[User:AcountName| Your Name]]
-''Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved''
+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).
-* Email: <your email address so we can contact you, invite you to meetings, etc.>
-== Current status ==
+{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;"
-* Targeted release: (SUGAR_VERSION)
+|-style="background:#787878; color: white;"
-* Last updated: (DATE)
+! Field
-* Percentage of completion: XX%
+! 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.)
+|-
+|}
-== Detailed Description ==
+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.
-''Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better.''
 == Benefit to Sugar ==
-''What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Sugar become a better platform or project because of this feature?''
-''Make sure to note here as well if this feature has been requested by a specific deployment, or if it has emerged from a bug report.''
+Out of sugar environment, users know that there is only one type of sugar objects and only thing they should do to activate them is uploading ''.xo'' file to Journal and click it.
+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 ==
-''What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?''
+* sugar
+* sugar-toolkit
+== UI Design ==
+Nothing except related [[Features/Activity as a regular Journal Object]] feature.
 == How To Test ==
 {{:{{PAGENAME}}/Testing}}
 == User Experience ==
-''If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice.''
+Since we have only one type of sugar objects, user all time knows that if there is a file with suffix ''.xo'' he can download/open-in-journal it and need only click to activate it in sugar.
 == Dependencies ==
-''What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like python?''
+Nothing except existed sucrose dependencies.
 == Contingency Plan ==
-''If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "None necessary, revert to previous release behaviour."  Or it might not.  If you feature is not completed in time we want to assure others that other parts of Sugar will not be in jeopardy.''
+None necessary, revert to previous release behaviour.
 == Documentation ==
-''Is there upstream documentation on this feature, or notes you have written yourself?  Has this topic been discussed in the mailing list or during a meeting? Link to that material here so other interested developers can get involved.''
+* [[Unified Bundles]]
+* [[User:Alsroot/trash/Unified Objects | Unified Objects]]
+* [http://wiki.laptop.org/go/Journal_entry_bundles Journal entry bundles]
+* [http://wiki.laptop.org/go/Bundle_concepts Bundle concepts]
+* [http://wiki.laptop.org/go/Manifest_Specification#Contents_Manifests MANIFEST specification]
+* 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/msg07572.html multiple activity versions installed simultaneously]
+** [http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06944.html Activity as regular objects proposal]
 == Release Notes ==