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 simply provide a direction.

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/ framework TBD).

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.

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.

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.

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.

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. Probably 6.x would be the target, since that's where most modules are probably at.

Looking at 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 knowledgable developers in order to make use of that flexibility. There is some expressions of hope that 0.7x 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.

Launchpad. Another alternative to Drupal would be to use Launchpad. The default interface is too geeky as a storefront, and I speculate 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.

A plausible implementation rollout is:

Summer 2010

1. 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 a new Agasti framework, though some of the HTML content may).
2. Develop design and implementation plan for App Store.

Fall 2010

1. Begin App Store implementation (if developers available).
2. Revise Agasti Module Manager as needed to interact with App Store.
3. If new Agasti framework determined, begin to develop Module Manager for it.
4. Test.

Later

1. Stir in Eden.
2. Launch.

See ideas under Agasti Module Manager