[SoaS] [Sugar-devel] Download experimental without being logged in
Thomas C Gilliard
satellit at bendbroadband.com
Tue May 11 17:01:39 EDT 2010
Aleksey Lim wrote:
> On Tue, May 11, 2010 at 05:37:52AM -0700, Thomas Gilliard wrote:
>> Is there anyway to tell what version (flavor) of sugar
> It already works, ASLO can grab SP version from useragent string
> and provide appropriate activity versions for download buttons (full
> version list is still accessible on activity history page).
I just finished updating ASLO for Mirabelle (0.88.0) compatability by
This updated Spreadsheet reflects changes:
"x 509 c" means it was changed in ASLO
(Mirabelle should be entered in comments also)
>> (and hardware),
> I guess we can grap x86/x86_64 info from useragent as well but not sure
> if it will help much since people just place binaries from their current
> distro to .xo thus there is not guaranty that it will work in other
> cases. It is fundamental issue w/ .xo, in my mind it is pretty useless to
> try to fix binaries issue and having only .xo deployment scheme at the
> same time.
>> a user is logging in with?
>> If so, could this trigger a custom list of activities for his/her
>> version to be listed?
> It is not custom list but list of the same activities but some of them
> (incompatible with user's SP) have additional hints around/instead
> download button.
>> If not, maybe there should be a signature (cookie?) mechanism developed
>> for sugar that ASLO could use to select the compatible activities to
>> It works for browsers....
>> Tom Gilliard
>> Aleksey Lim wrote:
>>> Hi all,
>>> The ASLO is based on Sugar Platform idea when if activity
>>> developer wants to be sure that activity will start, just declares
>>> Sugar Platform range e.g. 0.82-0.88. This scheme is simple - users
>>> need to know only SP range to judge will activity start or not.
>>> But it doesn't work in other cases like binaries, non-SP dependencies.
>>> These issues can't be solved within current ASLO (and current deployment
>>> scheme, "only .xo bundles"). But we can remove, inherited from AMO,
>>> practice when user should be logged in to download not public
>>> So, it will look like:
>>> * featured activities(and collections) are blessed by ASLO editors
>>> will just work on declared sugars
>>> * activities that just work on declared sugars
>>> * experimental activities
>>> work in some cases e.g. dependencies exist, machine is x86 etc.
>>> In all cases, user should not be logged in to download all these
>>> activity types. Does it break someone's workflows ?
>>>  http://activities.sugarlabs.org/
>>>  http://wiki.sugarlabs.org/go/0.86/Platform_Components
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SoaS