[Systems] API for activities.sugarlabs.org?

[David Farning]

On Fri, Mar 12, 2010 at 10:52 AM, Pablo Flores <pflores2 at gmail.com> wrote:

Sorry for being missing from this conversation for last couple of weeks.  I
have been spending all of my 'Sugar time' setting up a High Availability
cluster for activities.sugarlabs.org.  That is well on its way so I am
moving integrating aslo with ceibalJAM to the top of the list.

I am rather torn by the idea of separate portal vs. integrated portal.  On
one hand, open source development is driven by innovators forking an
existing project to meet their particular needs.  On the other hand,
premature forking could cause project fracturing.

One thing to consider is that the action CeibalJam takes is not limited just
to CeibalJam.  It will set the tone for other projects and deployments.

For full disclosure.... I started pushing for ASLO for the same reasons you
are working on the CeibalJam portal:
1.  I thought it was worth the effort of setting up and maintaining ASLO to
avoid the usability I felt existed in the OLPC activity distribution system.
2.  I wanted to establish ALSO and Sugar Labs as the place to get high
quality activities.
3.  I wanted to create a sense of Sugar Labs community around the portal.

This shifts the question into how do we balance the long and short term
interests of:
1. The students in Uruguay -- and other deployments.
2. CeibalJam -- and other local support organizations.
3. Sugar Labs as an upstream.


Single Sign In -- I took a look at the code and adding single sign in looks
straight forward.  ASLO session data is stored in the database so the only
change would be modifying the login page to accept openID credentials in
addition to username/password signin.  Using OpenID is a sovled problem in
CakePHP, the framework used, to develop AMO and ASLO.  This would be a win
for everyone.

Developer documentation -- Sadly, their is almost none. AMO, the system, was
designed as an inhouse 'infrastructure' solution to mozilla's 'how to
distribute addons' problem.  The same is true of ASLO.  The only good
documentation is in the code at
http://git.sugarlabs.org/projects/slo-addons. The other resources are
the #sugar on IRC and this mailing list.

Creating the Community  -- This seems to the crux of the discussion.  The
two big questions are:
1.  How does CeibalJam (and deployments/ local labs in general) create a
local identity to support its local developers and users?
2. How does Sugar Labs aggregate the effort and value of local deployment
into a global solution?

 The challenge with skining a page is that _every_ page is dynamically
generated based on user session information.  The urls are for _just_ for
passing information and improving user experience.  This weekend I will look
into how the translation systems works to select strings base on locale we
might be able to adapt that to select a .css skin.

My gut reaction is that while it is tempting to emphasise the importance of
local look and feel,  Uruguay, CeibalJam, and Sugar Labs will all benefit
from emphasising upstream when solving the problem of distributing
activities.  The cost of forking, and possible fragmentation, will quickly
overwhelm the benift of creating and supporting a separate activities
portal.

Possible way to move forward:
1.  Use ASLO as the user portal.  The hard problem is distributing
activities to the end users.  Sugar Labs solved that pretty well with ASLO
and the content distribution network.

2. Use the CeibalJam drupal site as an developer and educator portal.  The
more I look at it the more I see the value in the druple developer/educator
front end as an well designed http://wiki.sugarlabs.org/go/Activities :)
portal.  I have never been happy with
http://wiki.sugarlabs.org/go/Activities .... I just never had the time (or
idea how) to fix it.

Advantage of this approach are:
1. Consistency of user experience.
2. Emphasis on integration over fragmentation.
3. The druple developer/educator front end can be reused by other
deployments, deployment support organisations, and developer organisations
to create local communities and brands.

Action Items:
1. Add OpenID to ASLO.  Dfarning with review from alsroot and Silbe.
2.  Integrate ASLO with CeibalJam's druple site, Pablo with dfarning.
3.  Create CeibalJam ASLO mirror to serve Uruguay users. Pablo with
dfarning.
4. Generate download statistics for activities based on region.  I think
that we can modify existing tools to parse the logs for the local Uruguayan
mirror to determine Uruguayan activity download statistics.  Pablo?
dfarning?

Does this seem like a reasonable solution which does not compromise too
much?

david

I agree that 2 seems to be a better solution for integrating our works...
>
> What I don't like of this choice is the impossibility to skin the page. I
> think is a very important usability issue.
>
> I don't know if this may sound like a hack for you, but... isn't it
> possible to fix ASLO to change the <base href=...> folder depending on the
> locale, so different css (or other templates) may be used?
>
> BTW, where's tech info about ASLO and AMO?
>
>
> Saludos,
> Pablo Flores
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/private/systems/attachments/20100312/84e67e19/attachment.htm