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