On Tue, Jul 28, 2009 at 12:14:54PM +0200, Sascha Silbe wrote:
> On Tue, Jul 28, 2009 at 05:14:57AM +0000, Aleksey Lim wrote:
> >* it can't upgrade activities if they were pre-installed from
> >  native packages; it makes process of upgrading activities
> >  from .xo impossible
> Yeah, this is really a PITA.
> >* sugar can have only one activity version installed at the same
> >  time
> That's being worked on, see bug #1042 [1] (patch available, but not
> merged yet) and #1053 [2] (fixed).
> >i.e. it could be useful to have several versions
> >  simultaneously e.g. to start proper version when join request
> >  arrived(activity version of arrived request could be different
> >  to installed version)
> That's not implemented yet, of course, and needs further design
> decisions (esp. regarding the UI).
> >[1] http://wiki.sugarlabs.org/go/Features/Activity_Objects
> This sounds a lot like what I imagined as a solution for the first
> problem: represent system-installed activities as a virtual Journal
> object - inside Journal / shell only, not exposed to activities or
> the datastore.
> What I don't get is how this depends on your Object Bundles proposal
> [3]. AIUI the latter is only an on-the-wire format, similar to the
> way regular Bundles work now.

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.

> [1] http://dev.sugarlabs.org/ticket/1042
> [2] http://dev.sugarlabs.org/ticket/1053
> [3] http://wiki.sugarlabs.org/go/Features/Object_Bundles
> CU Sascha
> -- 
> http://sascha.silbe.org/
> http://www.infra-silbe.de/

Sugar-devel mailing list

Reply via email to