[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
activity
This updated Spreadsheet reflects changes:
http://people.sugarlabs.org/Tgillard/Activities-Index-Mirabell.ods
"x 509 c" means it was changed in ASLO
(Mirabelle should be entered in comments also)
Tom Gilliard
satellit
>> (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
>> display.
>>
>> It works for browsers....
>>
>> Tom Gilliard
>> satellit
>>
>> Aleksey Lim wrote:
>>
>>> Hi all,
>>>
>>> The ASLO[1] is based on Sugar Platform[2] 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
>>> activities.
>>>
>>> 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 ?
>>>
>>> [1] http://activities.sugarlabs.org/
>>> [2] http://wiki.sugarlabs.org/go/0.86/Platform_Components
>>>
>>>
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/soas/attachments/20100511/adf9cbde/attachment.htm
More information about the SoaS
mailing list