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

[Sebastian Silva]

Hello Sridhar,
I'm glad you are interested in this effort. I agree with you, what is
missing is making the activity discovery process smoother. This is one of
our objectives. I am in process of finishing a Technology Preview of our
WebSDK. With this component ready I expect to work on the design of the
Catalogue user experience during this month (offline and online). The WebSDK
will allow me to use the same code base for both front-ends. August I expect
to work on the backend - wether it is thru the updater (like Martin
suggests) or using the 0install infrastructure (which Aleksey just
described).

Anyhow I expect this project to make the activity ecosystem more like the
"marketplace" metaphor.

WebSDK RoadMap

   -  Initial Hello World of Sugar WebSDK - Beginning of July
               *(this week: Technology Preview 1)*


   -  Interface Design of Activity Pack Catalogue - July
   -  Implementation of Catalogue functionality - August

Greets
Sebastian

2011/7/7 Aleksey Lim <alsroot at activitycentral.org>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/dextrose/attachments/20110707/8c6f72e9/attachment-0001.html>