[Sugar-devel] Book bundles and Read
Gary C Martin
gary at garycmartin.com
Sun Jul 26 11:56:40 EDT 2009
On 25 Jul 2009, at 17:02, Aleksey Lim wrote:
> On Sat, Jul 25, 2009 at 04:24:33PM +0100, Gary C Martin wrote:
>> Hi Aleksey,
>> On 25 Jul 2009, at 05:02, Aleksey Lim wrote:
>>> On Sat, Jul 25, 2009 at 04:53:33AM +0100, Gary C Martin wrote:
>>>> The term "content bundles" is still pretty wooly for me. Are we
>>>> talking zip files, perhaps with some formal structure?
>>> Object Bundles will deprecate .xol in 0.86 and in case of
>>> it will be regular field in METADATA file:
>>> "preview_file = <file-inside-bundle-with-preview>"
>>>  http://wiki.sugarlabs.org/go/Features/Object_Bundles
>>>  http://wiki.sugarlabs.org/go/Features/Object_Bundles#METADATA_file
>> Thanks for the references. Having read that page I'm still confused
>> about aspects of this proposal. Not sure I'm clear enough to ask
>> sane questions. Let me try:
>> 1) By "composite object" do you mean a container of many
>> files/folders (a little like current .xol), or a container of many
>> Journal compatible entries (i.e. 40 Read Activity pdf ebooks with
>> thumbnail images, tags, and description)?
> Container of of many files/folders that represented by one Journal
> so, in case of library it would be: one entry in Journal which has
> and directory with content of library(somewhere). After activating it,
> Browse will open one of "many files/folders" e.g. index.html
>> 2) Is .xol extension proposed to go away, or will .xol be repurposed
>> as a the "composite object"?
> In case of  .xol is just a subset of object bundles
> and sugar will still support former .xol(but they will be deprecated)
>> 3) Why should a "composite object" open in Browse, is this just an
>> example of a zipped up web site?
> Because Journal entry which represent composite object will have
> text/html mime_type, in face there is only one difference between
> regular Journal objects and composite - regular object has only one
> file but composite has directory.
>> 4) Will .xo will be used to store Activity bundles (i.e as we have
>> now), and Activity entries (i.e. all meta-data and files as found
>> for a Journal entry)?
> Activity just another example of composite object(in common sense)
> and I'm thinking about adding them to 0.86 as well.
> According to  there could be two forms of object bundles:
> * one or several packed Activity entries
> (they can have activity field)
> * the while bundle as composite object which will be represented by
> Journal activity-less object (e.g. library or activity)
OK, I think I understand that :-)
1) 1 (to N) Activity entries, all wrapped inside the .xo, on download
to Journal they are all expanded as individual Journal entries. +1 :-)
2) A zipped folder of files/folders that is placed in the Journal as a
single entry (composite object). Question: Is this equivalent to
an .xol? Or, can it hold arbitrary files (i.e .xol is a subset), like
a bunch of C source files? Maybe you want to make a Gcc Activity to
open this composite object at some point? ;-b
>> 5) Meta-data kept in an INI rather than json a file?
> In INI format since its easier for hand-editing
>> What about non-
>> text meta-data, the preview image comes to mind, but an activity
>> might be storing other non text blobs of meta-data.
> 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 e.g. preview_file=<filename-from-bundle> to fill
> preview field.
Thanks, sorry I missed the relevance of that when reading your wiki
spec. Understood now. These would be some pretty useful/powerful
More information about the Sugar-devel