[Dextrose] Sugar WebSDK + Activity Pack

[Aleksey Lim]

On Sat, Jun 18, 2011 at 01:58:05AM -0500, Sebastian Silva 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.

Just to make clear my intenstions...
For me, ASLO+(ie, not current ASLO impl) and sweets are different level
entities. The picture I'm trying to implement is:

The core:

    * OBS (do not mess it w/ OBS's web client on build.opensuse.org):
      low level core, it handles source bundles and makes (if required)
      binaries from them, provides all this data for clients

    * OBS is reprented by its frontend, bazaar.sugarlabs.org
      it is pure HTTP based API that all clients use

The clients:

    * ASLO+, a web client for activity developers (ie, much easy
      workflow to upload activities than on OBS's web client, similar
      to he existed workflow on current ASLO) and a web catalog for
      final users with keeping all ASLO features like review, ranks,
      etc. In other words, the same what current ASLO does but it
      handles everething on its own and new ASLO+ will be just a client
      for OBS.

    * sweets CLI tool, a CLI client to OBS that allows to do the same
      what ASLO+ does (in case of activity uploading), plus some
      additions to work w/ local sweets(activities, libraries,
      applications)

    * packages.sugarlabs.org as a web client for OBS only for packagers
      (ie not activity developers). it is what build.opensuse.org is but
      w/ small UI additions to: let packagers reuse activities just by
      several clicks in UI. It is intended to help people in vary
      special cases like creating Sugar distros (Live, SchoolServer,
      etc) or for LTSP

    * and looks like new web based toolkit,
      with having a functionality to reuse precached sweet
      implementations that come from Activity Pack on, eg, USB stick


Some questions to be sure about your intentions:

1. Is it still about local/client side web based toolkit, ie, not for
   server side?

2. If yes, how big implementation might be, ie, MVC/TitaniumSDK-like
   doesn't sound like a trivial work.. what about more simple way like
   what Gnome3/KDE do for integrating web based technologies to their
   DEs (eg, there is JS code in gnome-shell,
   http://git.gnome.org/browse/gnome-shell/tree/js)

3. I've just remembered we already had/have some web based toolkit work
   in sugar, but can't remember exactly, maybe in Nepal
   (I've CCed to sugar-devel@)

> 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<http://wiki.appcelerator.org/display/guides/Getting+Started+with+Titanium#GettingStartedwithTitanium-TitaniumDesktopSDK>
> 

-- 
Aleksey