agasti:vesuvius:req_app_store

You are here: start » agasti » vesuvius » req_app_store
This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
=== Vesuvius ===
====== Requirements - App Store for Sahana Modules ======

//An App Store implementation was briefly pursued during Google Summer of Code 2010.  The circa-2010 discussion below was under wiki.sahanafoundation.org/phase2/doku.php/req:app_store.  It was momentarily resurrected as a project idea for GSoC 2011, but then postponed, pending a wider rethink of overall SSF web site needs.//

====== Summary of Ideas and Evolving Consensus ======

===== Background =====
The design and implementation plan for a Sahana App Store is being done in conjunction with a Google Summer of Code 2010 project for an Agasti Module Manager.  It is not expected that the GSoC effort will deliver an actual App Store implementation during the summer, but provide a direction and perhaps some experimental prototypes.

The extent to which the App Store roadmap discussed here is product-specific (e.g., Agasti) will have to be defined, as will the evolution of Module Managers to support it.  The server-side of the store can in theory be implemented in any convenient language and framework, separate from those used in Sahana-Eden (Python/Web2Py) and Sahana-Agasti (PHP/recently-chosen Symfony).

Ideally, an App Store could be built in such a way that it is generic and should work with both Agasti, Eden, and (further on) mobile components.  The modules will be cataloged referencing the platform and version, which will make finding compatible modules easy from a version of Agasti or Eden.  The system will basically deliver some compressed package and the respective Sahana version be responsible of installing it. 

===== Features and Architecture Supporting Sahana Modules =====

A Sahana App Store could broadly emulate the Android Marketplace and iPhone App Store.  Desirable features include: 

  * Module descriptions and screenshots
  * Version updates and change-logs
  * Automatic download / installation (and uninstallation)
  * Automatic module upgrades (as with Android 2.2)
  * Manual module upgrades (as with Wordpress)
  * User feedback and ratings
  * Version compatibility check with client framework and implementation ( filtered listing of apps)
  * Handling of other module dependencies

The main components are:

  * the server that will host the app store centrally.  Its functionally should be pretty much independent of framework, version, or implementation type.  It should be to be able to support multiple versions of Sahana.
  * the client libraries (specific to Agasti, Eden, etc.) that will install/uninstall the apps and otherwise interact with the store.

===== Eventual Support For Additional Store Offerings =====
After modules are well-supported, other potential offerings include:

  * GUI themes
  * Language packs
  * Database initial content (e.g., geographic place names and locations.  Likely implemented by SQL scripting)
  * Specialized tools (e.g., to quickly configure an instance for a particular type of disaster)
  * Mobile apps
  * T-shirts and other swag?

===== Policy and Process for App Store Contributions =====

An App Store needs to be considered from the new-module creator's perspective as well.  There has to be a contribution process, and policy decisions as to who can contribute or what degree of vetting if any a new module should get.  Do we follow the restrictive Apple approach, or is a looser way better?  Will rogue Sahana apps (as virus/identity theft vectors) become a problem?

It may be advantageous to follow the Android policy, giving the freedom to the administrator on what modules to install from the app store.  The store can provide a module stability ranking,  aligned to our release process (e.g. experimental, unstable, testing, stable).  By default, the system should be configured to filter through only stable (and possibly testing) modules, with the admin allowed to increase his risk by permitting experimental or unstable modules in his search results. 

The pending-ratification release strategy [link?] covers much of this, especially the parts pertaining to packaging/release.  A workflow management diagram/document is due out shortly as a reference guide for people to follow.

Even with a generally open approach to modules, there's a place for identifying those modules owned by an //organisation//, that would:

  * manage the module
  * commit to certain standards (e.g., keep it up to date, respond to issues in a timely manner)
  * provide SFF with a great way of recognising organisational contributions.

===== Store Server Implementation Ideas =====

The App Store would ideally be hosted on sahanafoundation.org

In theory, an off-the-shelf e-commerce system could be used for the app store.  An example would be Zen Cart E-Commerce Shopping Cart (on SourceForge, written in PHP).  Or perhaps a PHP-library updating system like PEAR/openpear.

//Drupal//

Perhaps more appealing would be a more general purpose, but module-rich, framework like Drupal.  In that regard, Drupal is the CMS behind sahanafoundation.org. (It is a very old 5.x version, and needs a major update urgently, and a new template).  Assuming the SSF Drupal is brought up to date, the App Store could be built into the existing SSF website.

There's three incompatible cohorts of Drupal modules, 5.x, 6.x, and (alpha) 7.x.  From one point of view, 6.x would be the best target, since that's where most available and tested Drupal modules are.  From another view, v6 has been around for a while now, so if that is adopted for the App Store, it won't be long before an upgrade to v7 is needed.  Could we hold out until v7 (and needed modules) are released?

Looking at Drupal modules, there are two main ecosystems of ecommerce store modules, "ubercart" and "e-commerce".  These can handle free software distribution, but only as zero-cost catalog items within a paid/shopping cart context.  A little awkward, and evidently not capable of automatic versioning/updating.  (Nor does it appear that base Drupal itself has that, although there is a "drush" module that does some of that, as well as a proposed 2009 SoC student project "Automated Drupal Package Management Module".)  There are some modules that seem to do versioning ("project*" and "storm") at the file/media level, but not so much at the GUI.  It appears there is some work on App Store modules specifically targeted at cell phones.

The general rap on Drupal seems to be that it's very flexible, but requires knowledgeable developers in order to make use of that flexibility.  There is some expressions of hope that 7.x would help in the crafting of versions as easy as Wordpress to setup and customize.  An example would be www.drupalgardens.org, that generates a hosted microblogging site based on 7.x alpha.  It incorporates a WYSIWYG theme editor.  Hosting is free until year's end, then either ads appear, or you pay, or you migrate the site to your own box.  But the purpose is limited to blogging.

One possible roll-your-own Drupal implementation approach to an App Store would be to create a custom 'App' content type that extends Drupal's default node type.  Then, one or more controlled taxonomies could be created - one, for example, may contain version numbers.  Each time a different version of a module is uploaded, a new App node is create with a different version from the controlled taxonomy.  This way the Store could support multiple versions of a module targeted at different revisions of Sahana Agasti or Eden, or any future products the Foundation may have.

//Launchpad//

Another alternative to Drupal would be to use Launchpad.  The default interface is too geeky as a storefront, and probably it's harder to change that than with Drupal.  But it does have the versioning/auto-update feature, particularly in the form of Personal Package Archives (PPA) used to update applications for Ubuntu.  Presumably the PPA code could be sucked from Ubuntu and inserted into Sahana.

This approach could be viewed as a complement to the App Store rather than an alternative.  Launchpad makes sense for development and initial hosting, as eventually Sahana modules can be packaged for Ubuntu and made available through apt-get as well.  The App Store concept is over and above this and presents a more user-friendly approach, whereas apt-get integration through LP is more for the serious developer or Sahana administrator.

===== Initial Experimentation =====
In June, 2010, GSoC student Kusum Kumar Madarasu, working on the Agasti Module Manager project, started learning about Drupal 6/7 and its modules of potential pertinence to an App Store.  He first considered a Drupal 6 + Ubercart architecture with Acquia Prosper theme.  The current prototyping direction drops Ubercart, in favor of a native Drupal custom node approach.

===== Conjectured Timeframe =====

A plausible implementation rollout is:

//Summer 2010//
  - Complete stand-alone Agasti Module Mangager, with some awareness of App Store issues.  This will work with the current version of Agasti.  (The code logic will not be expected to forward port easily to the newly-chosen Symfony framework, though some of the HTML content may).
  - Develop design and implementation plan for App Store, with experimental prototypes.

//Fall 2010//
  - Based on findings, move to real App Store implementation (if developers available).
  - Revise Agasti Module Manager as needed to interact with App Store.
  - Begin to develop Module Manager for Symfony framework.
  - Test.

//Later//
  - Stir in Eden.
  - Launch.

===== Agasti - For Much More =====

See ideas, links under [[agasti:vesuvius:module_manager | Vesuvius Module Manager]]
Trace:
Navigation

Quick Links:

Search

Toolbox

QR Code
