A bundle in Sugar terminology is broadly speaking a zipped collection of files including metadata defining its name and origin.
Here is some terminology oriinally uesd when defining bundles:
- Objects - a single file; a drawing, story, photo, sound, etc. Objects are not necessarily bundles.
- Bundle - a type of object. A bundle is an object that contains multiple other objects within it, and which opens with a bundle activity.
For instance: A .png of a cat is an object. A collection of pictures of cats and a Write document that includes all these pictures could be packaged up in a bundle, which would open with an appropriate bundle activity.
Since bundles are just a special type of object, the same tagging and sharing interface should be used for both bundles and objects.
As currently described on the wiki, there are three main types of bundles that have their own specifications beyond the standard bundle format.
- Activity bundles - collections of non-child-produced materials used for a particular activity. For instance, a selection of Etoys tutorials created by the etoys team is an activity bundle.
- Content bundles - collections of non-child-produced materials used in the Library specifically. These use the .xol file format detailed by Lauren in Creating a content bundle. For instance, a collection of Wikipedia articles in Arabic is a content bundle.
- Extended content bundle - a proposed format. this would refer to collections of files that don't qualify as either of the above -- either because they don't have the superstructure of an activity with a single executable, or that of an html directory; or because they are more transient and not intended to persist over months and years (so some of the metadata can/should be autogenerated and arbitrary).
Some ideas for improvement
This is not an ideal set of terminology - it's been proposed (by Eben) to move to the following:
- Bundle - an object that contains multiple other objects within it. A specification is available at Bundles; bundles take the form of a .zip folder containing the objects they are bundling; that is all. There is no distinction between child-created and non-child-created bundles. By default, bundles are opened with the Bundle activity.
- Extended bundles - any bundle format with a superset of the requirements of the basic bundle bundle format. The extension may include a type identifier and/or owner such that these bundles open with various appropriate activities by default. There are currently three common extended bundle formats:
- Object bundle - a bundle format that includes additional metadata and requirements that make it possible to use a bundle within and with a specific Activity. There is no set specification for an object bundle, although individual Activities may have their own object bundle format requirements. An object bundle format allows an object bundle to be treated like an object and opened with any activity which recognizes it.
- Activity bundle - a bundle that defines an activity object which can be instantiated as a running application on the laptops. Activity bundles are really just a specific form of an "object bundle." The specification for activity bundles is available at Activity bundles and instructions on creating one are available at Creating an Activity bundle - note that these instructions use sugar.activity.bundlebuilder which is the only way to create an activity bundle at present.
- Content bundle - the .xol file format detailed in Creating a content bundle that adds metadata requirements that make it possible to use the bundle within the Library.
As an aside, we could instead argue that the "object bundle" should simply be the "extended bundle", and that "activity bundles" and "content bundles" are simply specific examples of extended bundles.
Creating an extended bundle format
As discussed above, it is possible to create extended bundle formats for specific uses. Extended bundle format specifications are supersets of the base bundle specification. The Activity bundle format and Content bundle format are the two most common extended bundle formats, but it is possible for people to create their own - usually as a superset of the Object bundle format. The most common usecase for this is if an Activity requires certain metadata to be in a bundle before you can use that bundle within the Activity - for instance, Write requires certain file formats and metadata to be present in a document object in order to open and edit it.
To create an extended bundle format, simply take the existing bundle format and specify additional features (metadata to include, directory structures or files to follow, etc), then include a .info file in the top level of your bundle containing information about your bundle type. is there a spec for this .info file? However, we recommend that you try to avoid creating additional formats whenever possible, and to keep your formats as broad and generally usable as possible; the current bundle formats have been designed for maximum flexibility.
We need clearer discussion of bundling. Some bundling use cases [BUCs]:
Use case 1
BUC-1 : I take a photo and make a drawing. You make a collage. I send you the photo and drawing so you can include them in the collage:
- by starting both Draw and Record and sharing them; you then choose to join the shared sessions and export the drawing and photo, then start Write and import them.
- by saving both photo and drawing as "Public". I now can browse to a view of your Journal, or search my local net of Journals and filter by creator, and find them.
- by saving both photo and drawing with a specific tag (sj-maria-collab) so you can find them later. Bonus: automatic tagging when you synch with flickr and myspace and whatnot.
- by exporting both photo and drawing to "Web" and letting me know, I can now browse to your public "Web" space with the browser and find them.
- by launching the Bundlemaker activity (for making 'extended' bundles), and selecting the photo and drawing from my Journal history. Then I name the resulting extended bundle "sj-maria-collab" and share it with you...
- ...you can now find it from your mesh view
- ...you now receive an alert that there is a bundle waiting for you
- ...the bundle immediately starts migrating across an ad-hoc file-sharing network, using space explicitly made free for this purpose by anyone who has started the fileshare Activity.
- by publishing a local-permalink to the entries in my Journal as a catalog-update, either just for you or for everyone nearby; and sending it to you; your catalog daemon now updates your local catalog with metadata about the two pieces, and they show up in your journal view as available links and in the first results you get when searching for new material on your network.
Use case 2
BUC-2 : I make a webpage on the school server. You like it and save a local copy on your XO, including images. The next day you want to share the page with João:
- by opening Browse and sharing a session while it is loaded
- by going into your journal and sharing a journal-view of the saved item
- by making an explicit content bundle out of the page and sharing it with João.
- by making an explicit extended bundle out of the page and sharing it with João (see above for options)