[Sugar-devel] Book bundles and Read

[Eben Eliason]

On Sun, Jul 26, 2009 at 11:56 AM, Gary C Martin<gary at garycmartin.com> 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), like a bunch of C
> source files? Maybe you want to make a Gcc Activity to open this composite
> object at some point? ;-b

I've always envisioned a "Bundle" activity which is a glorified
tar/zip/other-bundle-format viewing and creation tool. With Bundle, it
would be possible to open any such file in the Journal (including
activity bundles, of course) to view its contents. It would also
support extracting all or part of the bundle contents to separate
Journal entries, as well as creating new bundles from arbitrary
collections of objects.

It would even be possible to add collaboration on top of this, so
groups of kids could create bundles together, aggregating entries from
each of their Journals into a single product. This would be useful for
group projects, for instance.

I know a class took this on as a project at one point, though I never
heard how that turned out. I believe
this—http://activities.sugarlabs.org/en-US/sugar/addon/4079—is the
result, but I haven't had a chance to try it yet. In any case, it
might be nice to keep it in mind, and perhaps extend its features in
line with these new discussions for object bundles if appropriate. For
instance, it might be possible to add some GUI tools for
viewing/populating Sugar-specific manifest files, when desired.

As a side note, I have an icon for "Bundle" which we've had around
since the early design stages of Sugar, and the icon shown there isn't
HIG compliant. Jake, would you be willing to update the bundle with a
new icon if I supplied you with one?

Eben


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