On Tue, Jul 28, 2009 at 01:01:32PM +0200, Sascha Silbe wrote:
> On Tue, Jul 28, 2009 at 10:37:18AM +0000, Aleksey Lim wrote:
> >Since [3] is(in addition) an idea of having "composite" Journal
> >objects(when we have content of bundle stored somewhere in form of
> >ready to use directly, and this content is represented by one Journal
> >item) we can treat activities like a composite objects.
> >
> >So, the idea is having Journal entries that should represent
> >activities
> >(they are regular Journal entries and users can search/tag/etc. them)
> >and each of these Journal entries has "entry" field which points to
> >directory with activity. Shell can find() DS to be aware of what
> >versions/activities it has to start proper
> >activity/activity-version to
> >activate particular object in Journal.
> So [3] is intended to be used inside Sugar itself? I don't think I
> like that. :-P
> What's the reason for
> a) storing several, different entities in the datastore object?

The original purpose was fixing ugly(imho) situation with library
bundles, we had .xol in Journal, unzipped library in ~/Library, library
sidebar in Browse to open libraries. [3] simplifies process, so we have
only Journal entry which represent library (we can utilize regular(not
yet implemented) Journal features like [4] and [5] to browse and open
these libraries). 

> b) storing actual content outside of the datastore?

In fact it was temporary decision(but it works fine w/o dirty hacks)
later we can move it to DS(we can get feedback in 0.86 cycle and maybe
even change/remove OB at all).

[3] http://wiki.sugarlabs.org/go/Features/Object_Bundles
[5] http://wiki.sugarlabs.org/go/Design_Team/Proposals/Journal#Tags_palette

Sugar-devel mailing list

Reply via email to