[Sugar-devel] Book bundles and Read

[Aleksey Lim]

On Sun, Jul 26, 2009 at 04:56:40PM +0100, Gary C Martin wrote:
> 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),

yup, arbitrary files
library bundle is just a good example

btw another good example is activity bundles
but adding activity bundles requires more coding except just adding
them to OB. Anyway I think its really doable in 0.86 cycle

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

-- 
Aleksey