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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel