[Sugar-devel] [IAEP] addons.sugarlabs.org is starting to work

[David Farning]

On Fri, Feb 20, 2009 at 11:18 AM, Carol Farlow Lerche <cafl at msbit.com> wrote:
> How does the Mozilla add-on functionality decide if there is a version or
> platform conflict for browser add-ons?  it must be a piece of the browser
> that does this via some interaction with data on the server.  Shouldn't
> there be a similar process here?  It is frustrating to download something
> (which can be a problem with bad/intermittent connectivity)  only to find
> that you can't use it.

Your browser reports information on the OS and browser version to
aslo.  A developer can select which OS and browser version for which
they want the activity to work.  My guess is that we will either need
to pin a specific version of browse to a os release or else have
browse report OS information.

BTW, amo, which we call aslo, also handles all of the messaging
passing for firefox to update itself daily.  The hooks are there.  We
just need to figure out how we want to use them.

david

> On Thu, Feb 19, 2009 at 9:12 AM, Wade Brainerd <wadetb at gmail.com> wrote:
>>
>> On Thu, Feb 19, 2009 at 6:15 AM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
>>>
>>> A long time ago, when using bundles was decided as necessary, the idea
>>> was that there would be something called the "Sugar platform" that
>>> would specify every component that an activity author can rely on
>>> being available for their activities to use.
>>>
>>> That would include etoys, csound, pygame, glibc, gtk, and any other
>>> components on which the sugar shell may not depend but activities can
>>> expect to be there.
>>
>> I've been part of this discussion a couple of times now and to me it seems
>> like the original vision is pretty much the right way to go.  As an activity
>> author I love the simplicity of activity bundles just being ZIP files.
>>
>>>
>>> Everything on which an activity depends and isn't part of the platform
>>> should be bundled inside the .xo.
>>
>> Aside from this point!  Some dependencies are simply too complex to
>> bundle, and can introduce conflicts with the host system.
>> Aleksey proposed adding a simple "depencencies" line to activity.info.
>>  This would be parsed by Sugar in a distribution specific manner by a
>> running 'sugar-check-dependencies' script that could be provided by each
>> distribution.  We would define our own set of dependency names and manually
>> map them to each distro that we package for.
>> For example, a 3D activity which used OpenGL could list "dependencies =
>> opengl", and then the various distributions could handle that as needed in
>> the script.
>> If the system does not contain the required dependencies for an activity,
>> in my opinion Sugar should prompt the user to install the dependencies and
>> then not launch the activity.
>> Best,
>> Wade
>>
>> _______________________________________________
>> IAEP -- It's An Education Project (not a laptop project!)
>> IAEP at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/iaep
>
>
>
> --
> "It is difficult to get a man to understand something, when his salary
> depends upon his not understanding it." -- Upton Sinclair
>
> _______________________________________________
> IAEP -- It's An Education Project (not a laptop project!)
> IAEP at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>