[OLPC-AU] Activity Market [WAS: Sugar WebSDK + Activity Pack]

Thu Jul 7 15:58:05 EDT 2011

On Thu, Jul 07, 2011 at 11:26:04PM +1000, Sridhar Dhanapalan wrote:
> I like the notion of making activities easier to find and install. The
> feedback that we've received is that ASLO is too messy, and the
> process isn't smooth enough.

Yeah, current ASLO is not good enough but we might keep in mind
different things where it is bad :). What are your points?

> The idea I had was to have an Activity Market, similar to the Android
> Market or the Apple App Store. This would be a place where activities
> could be easily managed directly on the XO. You should be able to
> easily browse through, search for, install and remove activities. I
> think that this model would work well,

You mean having non-web based UI on XO? If I got Sebastian right, his
idea is exactly about that (though Implementation might be different).

> usually self-contained.

Thats the one of problems in current ASLO and Sugar distribution methid
(.xo) at all. Not all activities are flat (have only sugar deps), and if
we are talking about "create your activitiy" we will get more and more
activities w/ non-sugar deps. Another problem is binary based activities
(the same point as w/ "create your activitiy").

Well, some people prefer
having self-contained activities in that case (having all deps and all,
for binary based activities, blobs bundled), in my mind that eventually
we will have situation when there is no any guaranties that particular
.xo will run in current environment - it is hard to ask any activity
developer (maybe a kid) to take care what deps he needs to bundle (some
sugar environments might have them preinstalled, another might not, etc.),
for binary based activities it is even worse (ABI/arches mess).

In my mind it is faulty to think that activities are self-contained,
of course if we talking to people "lets create your activity" and not
"lets create your activity with current sugar dependencies" (the last
"lets" sounds to me pretty non sugar way). But..

> How does your idea differ from this?

..there is another idea - 0install[1] based distribution method[2].
It is not yet described properly on the wiki, but the basic idea is:

to split the whole system of activities distribution/sharing to:
  1 hosting/building(for binary based activities)
    all files and metadata about activity will be handled on the
    server w/ only API (no any UI)
  2 activities catalog repsentation might be different - web (like aslo),
    local sugar UI (analog of F3 view but w/ access not only to local
    activities, eg, like Ubuntu App Center, and w/ having stuff like
    ranks/reviews), or even CLI access

the 1st part is started more than a year ago and it turned to start
being a regular package management system based on 0install, it is named
Sweets. It works in some initial stage (sugar, since there is no tech
difference between sugar iteself and sugar activities, runs more or less
from sweets; there is also a sweet based launcher for sugar shell).

imho, it might be useful to think about new/old/old-modified
activities catalog not in *AppStore way (when it behaves like ASLO, ie,
directly handles activity bundles and its metadata) but having just
a catalog of activities to let people launch activities and see/change
metadata like ranks/reviews, and delegate all not trivial stuff (like
handling deps and binaries) to the Sweets.

[1] http://0install.net/
[2] http://wiki.sugarlabs.org/go/Platform_Team/Sugar_Doers_Kit

> Cheers,
> Sridhar
> 
> 
> On 18 June 2011 16:58, Sebastian Silva <sebastian at somosazucar.org> wrote:
> > "The most important part of a christmas gift is the packaging." - My
> > father-in-law (acording to my wife)
> >
> > Dextrose Activity Pack
> >
> > As maybe you know, we started giving some maintenance to a collection of
> > activities - the Dextrose Activity Pack. These activities will come with
> > Dextrose but you will also be able to download them as a pack.
> >
> > My plan is you will be able to download an activity catalogue.  Think of
> > "Add & Remove Activities" like in Ubuntu, except activity bundles may come
> > precached so that you can download an entire "Activity Pack" into USB or
> > otherwise distribute offline or online as a single download.
> >
> > Currently ASLO, Sugar Labs's Activity Library does not cover this.
> > Obtaining/updating several activities at once over a slow link is a pain.
> >
> > Deployments could use this mechanism to distribute new activities / updates.
> >
> > The Catalogue
> >
> > Looking at the catalogue, I think it should be visually attractive, have
> > screenshots, authors, a description. It could even offer a way to provide
> > feedback for each activity and/or interact with other users.
> >
> > In order to provide an interesting package system for deployers and end
> > users, I think I need to focus on building this Catalogue, make it really
> > nice and user friendly.
> >
> > The Sugar WebSDK
> >
> > I've decided to develop a framework for the approach I'm taking with the
> > Catalogue. The pattern is known as Model-View-Controller and is widely used
> > in web industry and other places [0].
> >
> > In short, we provide a View layer that is powered by Webkit. This layer is
> > connected thru events with the Controller layer, which is implemented in
> > Python. The Controller interacts with the Model, also in Python, the layer
> > which handles data. In turn, the View may be updated. Javascript will also
> > be available.
> >
> > The good part is that all the components are already there. I've been doing
> > research and I found Python Webkit DOM Bindings [1]. The point of Sugar
> > WebSDK is not making Web .xo bundles, but implementing the GUI part of the
> > activity (except for sugar toolbars) as a Webkit window, effectively turning
> > it into a GUI toolkit engine. A similar approach was taken by "Titanium
> > Appcelerator Desktop SDK" [2] which powers the Status.Net Desktop client
> > [3].
> >
> > I believe the ability to effectively make attractive interfaces in PyGTK is
> > pretty scarce. Doing so is also very time consuming. OTOH there is a
> > huge, mature offering of talented web designers out there. Embedded
> > javascript might allow for interesting visual tricks like jquery's fade
> > effects, or even full HTML5 gadgets/widgets.
> >
> > I expect the Activity ecosystem can make good use of a framework which
> > allows to distribute the production of an Activity among a team that
> > can include traditional HTML/CSS designers. I know we can.
> >
> > I intent to make this WebSDK a Sugar Labs project. This framework will be
> > shared to the developer community with a tutorial and of course, will be
> > used to build the Activity Pack Catalogue.
> >
> > RoadMap
> >
> > Initial Hello World of Sugar WebSDK - Beginning of July
> > Interface Design of Activity Pack Catalogue - July
> > Implementation of Catalogue functionality - August
> >
> > This would be enough for a first "beta" release.
> >
> > Focus after that should be on polish and documentation for a release of both
> > the WebSDK and the Activity Pack Catalogue.
> >
> > Help appreciated
> >
> > Currently I'm done with researching and ready to implement. If I missed
> > something it'd be nice to know, as well as general feedback on the WebSDK
> > idea. I especially appreciate prior experience and gotchas that may save me
> > time.
> >
> > Open questions remain with the back-end package functionality: How it all
> > interacts with ASLO and the Sugar update mechanism.
> >
> > I'm inspired partly by some insights Lucian had with Webified. Also Alsroot,
> > with the brilliant sweets project.
> >
> > My impression: ASLO+ project and Sweets packaging system could probably be
> > the backend medium term. An implementation reusing Anish's metadata updater
> > code is probably the lowest hanging fruit.
> >
> > Sincerely,
> >
> > Sebastian
> > Somos Azucar
> > Activity Central Activity Team
> >
> > [0] - http://en.wikipedia.org/wiki/Model_View_Controller
> > [1] - http://www.gnu.org/software/pythonwebkit/
> > [2] - http://developer.appcelerator.com/doc/desktop/python
> > [3] - http://status.net/desktop
> >
> > _______________________________________________
> > Dextrose mailing list
> > Dextrose at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/dextrose
> >
> >
> _______________________________________________
> OLPC-AU mailing list
> OLPC-AU at lists.laptop.org
> http://lists.laptop.org/listinfo/olpc-au

-- 
Aleksey