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

[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


Attachment: signature.asc
Description: Digital signature

Sugar-devel mailing list

Reply via email to