Difference between revisions of "User:Alsroot/trash/Object Bundles"
| Line 34: | Line 34: | ||
Object bundle can be installed to Journal in two forms: | Object bundle can be installed to Journal in two forms: | ||
| − | * files from bundle will be unpacked and installing as separate files, bundle itself will be removed(similar to .xoj)<br>''METADATA'' should not contain ''[ | + | * files from bundle will be unpacked and installing as separate files, bundle itself will be removed(similar to .xoj)<br>''METADATA'' should not contain ''[Entry]'' section |
| − | * bundles will be installed as a composite object i.e. as a directory of packaged to the bundle files<br>''METADATA'' should contain ''[ | + | * bundles will be installed as a composite object i.e. as a directory of packaged to the bundle files<br>''METADATA'' should contain ''[Entry]'' section |
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. | 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. | ||
| Line 41: | Line 41: | ||
==== [Metadata] section ==== | ==== [Metadata] section ==== | ||
| − | This section is mandatory. It describes Datastore metadata fields of final entry in Journal. If bundle is composite(section ''[ | + | This section is mandatory. It describes Datastore metadata fields of final entry in Journal. If bundle is composite(section ''[Entry]'' presents) this section defines Journal entry to represent composite object, otherwise Journal entry for ''[Metadata]/entry'' file. |
{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;" | {| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;" | ||
| Line 49: | Line 49: | ||
! Notes | ! Notes | ||
|- | |- | ||
| − | | '' | + | | ''entry'' |
| mandatory | | mandatory | ||
| − | | if bundle is composite, '' | + | | if bundle is composite, ''entry'' defines access point to composite object (e.g. index.html for library bundles); otherwise it defines file which will be installed to Journal |
|- | |- | ||
| ''mime_type'' | | ''mime_type'' | ||
| mandatory | | mandatory | ||
| − | | define metadata for a file which will be stored in Journal | + | | define metadata for a file which will be stored in Journal |
|- | |- | ||
| ''*'' | | ''*'' | ||
| Line 65: | Line 65: | ||
METADATA file could have several ''[Manifest]'' sections, in that case they should be parted by different suffixes e.g. ''[Manifest2]'', ''[Manifest.additional]'' etc. Multi-object bundles could be utilized in >0.86 for collections of objects or actions. | METADATA file could have several ''[Manifest]'' sections, in that case they should be parted by different suffixes e.g. ''[Manifest2]'', ''[Manifest.additional]'' etc. Multi-object bundles could be utilized in >0.86 for collections of objects or actions. | ||
| − | ==== [ | + | ==== [Entry] section ==== |
| − | If this section exists bundle will be installed as composite object i.e. all bundle files will be represented by one Journal entry(could be useful in case of libraries). | + | If this section exists bundle will be installed as a composite object i.e. all bundle files will be represented by one Journal entry(could be useful in case of libraries). |
{| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;" | {| border=1 cellpadding=3 style="border: 1px solid white; border-collapse: collapse; background: #e3e4e5;" | ||
| Line 74: | Line 74: | ||
! Flags | ! Flags | ||
! Notes | ! Notes | ||
| + | |- | ||
| + | | ''exec'' | ||
| + | | optional | ||
| + | | how to activate Journal entry, overrides ''[Metadata]'' fields(like ''activity'' and ''mime_type'') | ||
|- | |- | ||
|} | |} | ||
Revision as of 00:33, 25 July 2009
Summary
- package Journal objects to bundles to preserve sugar related metadata
- support composite Journal objects e.g. in case of library bundles instead of having .xol in Journal and unpacked files in ~/Library, all library files will be represented by one Journal entry, could be opened in Browse([Metadata]/mime_type should be text/html for that purpose) and could be transformed back to .xo on demand(e.g. for uploading library in Browse's pick-file field).
Owner
- Name: Aleksey Lim
- Email: send an email
Current status
- Targeted release: 0.86
- Last updated: Tue Jul 21 02:18:17 UTC 2009
- Percentage of completion: 0%
Detailed Description
This feature is a first approach to unified format for all types of bundles(in 0.86 it will support only Journal entries and new library bundles).
Bundle files hierarchy
- MANIFEST EOL-terminalted list of files inside bundle
- METADATA file in INI format which describes bundle
METADATA file
Object bundle can be installed to Journal in two forms:
- files from bundle will be unpacked and installing as separate files, bundle itself will be removed(similar to .xoj)
METADATA should not contain [Entry] section - bundles will be installed as a composite object i.e. as a directory of packaged to the bundle files
METADATA should contain [Entry] section
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.
[Metadata] section
This section is mandatory. It describes Datastore metadata fields of final entry in Journal. If bundle is composite(section [Entry] presents) this section defines Journal entry to represent composite object, otherwise Journal entry for [Metadata]/entry file.
| Field | Flags | Notes |
|---|---|---|
| entry | mandatory | if bundle is composite, entry defines access point to composite object (e.g. index.html for library bundles); otherwise it defines file which will be installed to Journal |
| mime_type | mandatory | define metadata for a file which will be stored in Journal |
| * | optional | any system, users predefined and arbitrary Datastore field |
METADATA file could have several [Manifest] sections, in that case they should be parted by different suffixes e.g. [Manifest2], [Manifest.additional] etc. Multi-object bundles could be utilized in >0.86 for collections of objects or actions.
[Entry] section
If this section exists bundle will be installed as a composite object i.e. all bundle files will be represented by one Journal entry(could be useful in case of libraries).
| Field | Flags | Notes |
|---|---|---|
| exec | optional | how to activate Journal entry, overrides [Metadata] fields(like activity and mime_type) |
MANIFEST file
File which contains a new-line-terminated list of file names inside bundle.
Benefit to Sugar
This feature is a first approach to unified format for all types of bundles.
Current implementation is similar to .xoj bundles except that:
- it uses INI format instead of json(to make it more user-editing friendly)
- any field's value could fetched from file inside of the bundle
- supports multi-object bundles
Scope
- deprecate .xol bundles
- deprecate .xoj bundles
- provide unified format for metadata file in .xo bundles which should support
- activities, former .xo bundles (0.88)
- libraries, former .xol bundles (0.86)
- journal entries, former .xoj bundles (0.86)
- make Browse upload object bundles when the server says so
- make Browse open bundles with libraries
How To Test
- Create a new TurtleArt activity
- Upload the new entry to the SL wiki using Browse
- Use Browse to download the entry back to Journal
- Resume it from Journal
User Experience
Except that .xoj has:
- users can create object bundles outside of sugar(they do not have to follow JSON rules)
Dependencies
Fructose dependencies.
Contingency Plan
None necessary, revert to previous release behaviour.
Documentation
Release Notes
The Sugar Release Notes inform end-users about what is new in the release. An Example is 0.84/Notes. The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns. If there are any such changes involved in this feature, indicate them here. You can also link to upstream documentation if it satisfies this need. This information forms the basis of the release notes edited by the release team and shipped with the release.