[Sugar-devel] Book bundles and Read

[Gary C Martin]

Hi Aleksey,

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[1] will deprecate .xol in 0.86 and in case of  
>>> previews,
>>> it will be regular field in METADATA file:
>>> "preview_file = <file-inside-bundle-with-preview>"
>>>
>>> [1] http://wiki.sugarlabs.org/go/Features/Object_Bundles
>>> [2] 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  
> entry
> so, in case of library it would be: one entry in Journal which has  
> text/html
> 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 [1] .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.

+1

Thanks, understood.

>> 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 [2] 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  
> one
>  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  
additions!

Regards,
--Gary