| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
req:app_store [2010/05/24 20:20]
glenn More from email thread |
req:app_store [2010/12/18 17:35] (current)
|
| |
| ===== Background ===== | ===== 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 simply provide a direction. | 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/ framework TBD). | 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. | 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 ===== | ===== Features and Architecture Supporting Sahana Modules ===== |
| |
| A Sahana App Store could broadly emulate the Android Marketplace and iPhone App Store. Desirable features include: | A Sahana App Store could broadly emulate the Android Marketplace and iPhone App Store. Desirable features include: |
| * 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 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. | * 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 ===== | ===== Policy and Process for App Store Contributions ===== |
| The App Store would ideally be hosted on sahanafoundation.org | 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. | 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. |
| |
| //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. | 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. |
| |
| 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. | //Launchpad// |
| |
| 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. | 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. |
| |
| 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. | 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. |
| |
| //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. | ===== 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 ===== | ===== Conjectured Timeframe ===== |
| |
| //Summer 2010// | //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 a new Agasti framework, though some of the HTML content may). | - 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. | - Develop design and implementation plan for App Store, with experimental prototypes. |
| |
| //Fall 2010// | //Fall 2010// |
| - Begin App Store implementation (if developers available). | - Based on findings, move to real App Store implementation (if developers available). |
| - Revise Agasti Module Manager as needed to interact with App Store. | - Revise Agasti Module Manager as needed to interact with App Store. |
| - If new Agasti framework determined, begin to develop Module Manager for it. | - Begin to develop Module Manager for Symfony framework. |
| - Test. | - Test. |
| |
| - Launch. | - Launch. |
| |
| ===== Agasti - For More ===== | ===== Agasti - For Much More ===== |
| |
| See ideas under [[dev:agasti_module_manager | Agasti Module Manager]] | See ideas, links under [[dev:agasti_module_manager | Agasti Module Manager]] |
