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
_______________________________________________
SoaS mailing list
[email protected]
http://lists.sugarlabs.org/listinfo/soas
