[Sugar-devel] sugar-activity go.sugarlabs.org/MyActivty

[Aleksey Lim]

On Fri, Jun 25, 2010 at 09:33:46AM +0200, Tomeu Vizoso wrote:
> On Wed, Jun 23, 2010 at 11:45, Aleksey Lim <alsroot at member.fsf.org> wrote:
> > Hi all,
> >
> > I've finished initial teacher-student sharing model for GCompris and
> > going to release it...
> 
> Hi Aleksey,
> 
> checking that I have understood correctly, these activity bundles use
> any of 0install to fulfill their dependencies?

If you are asking about current 0install based activities on ASLO..
Those 0install based activities on ASLO contain directory with 0install
implementations. These implementations could be for example binaries for
several architectures or even per dependency ABI (like binaries linked
against libpython25.so libpython26.so etc). On activity launch, 0install
(which is also bundled to .xo) selects proper binaries (taking into
account what current arch is and what current libpython is). Also non-SP
deps could be bundled. So it sounds like extended variant of fully
bundled activities. 

It was solution in process and at the end I don't see any benefits to
create half-0install variant. So, I'm planing to move some logic to ASLO
(per arch uploads or even per deployment/distro like it proposed by
several people before switching ASLO to only SP model). And use pure
0install way to launch activities that require more complicated
dependencies e.g. when bundling deps to .xo is useless.

So, new scheme is not about bundles at all i.e. 0installed activities
will be regular 0install packages. How they can be launched in sugar?
At the beginning, I was thinking about ActivityLibrary activity that
will be something like ASLO but written in python.

> 
> Thanks,
> 
> Tomeu
> 
> > Since this feature was requested by paraguayeduca people I'll upload
> > en-es .xo to ASLO but it will be useful only for people with similar
> > environments i.e. locale (that's not for .mo files but for voices files,
> > bundle with all languages weights 60M), architecture, installed
> > packages (libpython). Handle all these variations by uploading .xo per
> > variant sounds pretty overkill (even after implementing per architecture
> > uploading on ASLO).
> >
> > My previous experiment with bundling 0install[1] repos to .xo and choosing
> > right implementation on startup has some ugly, form 0install view,
> > solutions and anyway doesn't make activity fully bundled in all cases.
> > So, I'm thinking to follow simpler scheme, do not add any logic to
> > bundled blobs (it will be just plain tarball) and use 0install directly
> > when logic is needed.
> >
> > Firstly, I was thinking about using 0install only for dependencies and
> > http://services.sugarlabs.org/ was initiated to "serve" schemes like [2].
> > But for now, urls for activities itself are needed. These urls will be
> > unique identifiers within 0install environment e.g.
> > http://services.sugarlabs.org/gcompris is an id for GCompris, so user can
> > type
> >
> >    0launch http://services.sugarlabs.org/gcompris
> >
> > to launch (it will be downloaded at first) GC. The same will be for
> > activities. The proper launch method could be different, for the first
> > time it could be only command line launcher like 0launch.
> >
> > I'm just wondering what the prefix for urls could be e.g.
> >
> >    htpp://go.sugarlabs.org/MyActivity
> >    htpp://run.sugarlabs.org/MyActivity
> >    htpp://launch.sugarlabs.org/MyActivity
> >
> > [1] to http://0install.net/
> > [2] http://wiki.sugarlabs.org/go/Documentation_Team/Services/Activity_Developers_Guide#Using_dependencies
> >
> > --
> > Aleksey
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> 

-- 
Aleksey